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(57) Abfltr^cti A server and method is 
provided tx provide a spectfta service to 
network w era. The server and method 
automatics ly provide oeer-to-server 
security us ng VLANs. The server man- 
ages VLAH based on the request from a 
user for enjatii^aeletingflotal ng/kavlng 
VLANa. i The server allows user to 
control groupings and overcomes the 
VLAN limjt with the filtering policies 
on the switching inftaitructore. In 
the secoraj aspect of invention, the 
server and- method provide a specific 
address bailed on requests from users. 
The server dynamically handles the 
management and facilitation of the 
requests. • The server offers users 
rcassignmefit of IP addresses from e 
first set of| characteristics to a second 
sat of characteristics with minimal user 
intervention. This allows users the ability 
to run a broader rang* of protocols. In 
the third aspect of invention, the server 
and method is provided to provide a 
rental) le IP address to a remote computer. 
The server allows pools of rentable 
addresses tp be maintained on one or 
more remote servers. Tha server can 
solve the shortage of the rentable IP 
addresses. 
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Ssnrer and Method For Providing Specific Network Services 



rigid of togfaygafrm 

This invention relates to an Internet access server such as described in U.S. 
Application Serial No. 09/742 ,006, filed December 22,2000, tho cojxtenta ofwhichare 
incorporated herein by reference. The preferred embodiment 
server described in U.S. Application Serial No. 09/742,006, wiHbi 
the SolutionIP 



ie Internet access 
referred herein as 



Badaaaaosi 9f the faymtioa 
Local Area Networics(LANs) are data communication networks that span a physically 
limited area. LANs allowusers tohave shared access to many common resources, such 



20 



as files, printers, or other communication devices. The concept ojf shared access to 
resources is central to the LAN philosophy. 

Security, on the other hand, in traditional LANs is a major probleak For instance, in 
broadcast networks, everyone can see every packet on the network. Therefore, without 
the use of Virtual Looal Ana Networks (VLANs), it is poasihls for users on the 
system to see netwenk traffic from or destined for other users. This presents a security 
problem for the system and Its users. 



25 



AVLAN is a logical subgroup within a Local Area Network that' offers an effective 
solution to the LANs problems. The major features of VLANs arc flexible network 
segmentation and enhanced network security. 

However, when VLANs are used for security and group collaboration, generally they 
have to be manually configured ahead of time, on switching hardware. Furthermore, 
there is a finite number of VLANs that the switching hierarchy can support and this 
physical limitation on the number of VLANs supported may be an issue. 



30 
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In addition, some network protocols require fully nrtitable Internet Protocol(TP) 
addresses to Amotion (eg. tunnelling protocols including Virtual Private Networks 
(VPNs)). Typically a user requesting a dynamic IP address can 
rentable or non-routable IP address depending upon the configurate >n of the Dynamic 
Host Configuration Protocol (DHCP) server on that network. 



Since in a traditional network; dynamic switching from non-routable to rentable IP 
address is not handled by the server, users are left to their own devises if they require 
a rentable IP address, but were served a non-routable IP address. 

Summary of tfift rnwrifmn 
It is an obj ect of the present invention to overcome one or more oft^e problems cited 
above* A first aspoot of the present invention is directed to a 
interpreting and processing VLAN tags coupled with server 
switching infrastructure for VLAN management 



rcommitnicatfa 



and method for 
ion with the 



A method according to the present invention for automatically provic ing enhanced and 
secure access to a group of users initiated by a non-technicaUy rained user on a 
computer network without the intervention of information systems p srsonnel includes 
the steps of receiving a request from the a user to establish the group of 

i 

users;configuring a network infrastructure to support the groupjproviding a group 
identiflenallowing users to join the group according to the group identifier; further 
configuring the network infrastructure to support the joining users; and dissolving the 
group based on predetermined rules. 

i 

A server according to the present invention provides enhanced and secure access to a 

group of users initiated by a non-teohoically trained user on a computer network 

i 

without the intervention of information systems personnel and includes a registration 
module to receive a request including a group identifier from the iiscr;a registration 
driver to register the user to access the group of users, assign the group of users and 
maintain registration information' and state information of a netwtak infrastructure 
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as3o dated with the group of users; a module to assign VLAN 
registration status; and a packet driver module to insert/remove 
packets based on registration status. 



togs based on 
VLAN tags from 



is automatically 
server. The server 
service in 



According to the aforementioned invention, user-to-server security 
provided using VLANs whose management is *»*+™n»t»d by the 
fhcdlhates user initiated group collaboration by placing users requesting the 
the same VLAN. Additionally, VLAN limits can be overcome through creative use of 
the filtering policies on the switching infrastructure. 

User-to-server security can be further provided by placing each ind Lvidual user into a 
separate VLAN. The server 1 s automation and management ofVLAJ I creation/deletion 
facilitates this process, which allows a user to control groupings of i isers into conamofl 
VLANs (La group collaboration). Further, the filtering policies implemented on the 
switches allow users to utilize a broad range of VLANs. 

Another aspect of tho present invention is directed to a server and method for 
dynamically providing an address according to users' requests. 



20 A method according to the present invention for dynamically marWng pools of IP 
addresses on a computer network with differ 
. pool to pool as required includes the steps of maintaining a registjry of user records 
and associated sets of characteristics; further maintaining a registry of CP address pools 
with associated sets of characteristics; receiving a request from a user to switch from 

25 a first set of characteristic^ 

in the registry so that the set of characteristics associated with tij user matches the 

i 

second set of characteristics; and assigning an IP address to the! user from the IP 
address pool associated with the second set of characteristics. 



30 A server according to the present invention dynamically manages poola ofTP addres 

cm a computer network with different characteristics and moves a user from pool to 
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pool as required, and includes a module to receive a request from a user to switch 



registration driver 
IP address pools 
a registry of user 



from a first set of characteristics to a second sat of characteristics^ i 
to register the user and assign an IP address to the user from 
associated with the second set of characteristics, and maintain 
records, associated sets of characteristics and IP address pools with associated sets of 
characteristics; and a DHCP module to issue an address scratching request to the 
registration driver and receive IP addresses from its registration drijver and allocate IP 
addresses to users* 



According to the aforementioned invention, the server dynam 



cally handles the 



management and facilitation of the requests. The server offers 
IP addresses from a first set of characteristics to a second set 
minimal user intervention* This allows users the ability to run i 
protocols. 



Another aspect of the present invention is directed to a server 
providing a rentable IP addre&s to a remote computer* 



reassignment of 
of characteristics with 
broader range of 



and method for 



A method according to the present invention for providing a route ble IP address to a. 

remote computer includes the stops of providing a pool of routabli " addresses on a 

i 

server, receiving at the server a request from the remote compute* to establish an IP 
tunnel between the remote computer and the server; establishing ail IP tunnel between 
the remorse computer and the server; farther receiving a request from the remote 
computer through the tunnel for the routable IP address from the Server, and further 
providing the routable IP address to the remote computer from the| server through the 
tunnel. 



30 



A server according to the present Invention provides a routable IP address to a remote 
computer, and includes a module to receive a request from th0 remote compute 
through a tunnel fee flic routable IP address; a registration driver to assign the 
routable IP address to the remote computer from a pool of routable DP addresses and 
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DHCP module to provide the roufcabl 5 IP address to the 



establish an IP tunnel ; and a 
remote computer through the tunnel 

According to the aforementioned invention, the server allows 
addresses to be maintained on one or more remote servers. The 
shortage of the IP rentable addresses* 



pools of routable 
server can solve Uxe 



Brief Deaoription of the Drawing 
FIG. 1 shows an example of a system structure of a first embodiment of the present 
10 invention. 

FIG. 2 shows an example of the core components and interactions bf the VBN server 
according to the first embodiment 

FIG. 3 shows an example of Registration processing according to the first 
embodiment. 

IS FIG. 4 shows an example of VLAN Group Administration ( Create VLAN Group ) 
processing according to the first embodiment 

FIG. 5 shows an example of VLAN Group Administration ( Show VLAN Group ) 
processing according to the first embodiment. 

FIG. 6 shows an example of VLAN Group Administration (Delete VLAN Group) 
20 processing according to the first embodiment 

FIG. 7 is a pictorial representation of a typical server connection in a hotel 
environment. 

FIG. 8 shows a functional block diagram of Fig.7. 

BIG. 9 shows an example of the care components and interactions of the server shown 
25 inFig.7. 

FIG. 10 shows an example of DHCP request processing. 

FIG. 11 shows an example of ARP request processing. 

FIG. 12 shows an example of unregistered HTTP request processing. 

FIG. 13 shows an example of registered HTTP request processing, 
30 FIG. 14 shows billing components and interactions. 
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FIG. 15 shows an example of the VBN Server 1000 according 
embodiment. 

FIG. 16 shows an example of the components and interactions 
1 100 according to a second embodiment.. 

FIG* 17 shows an example of Registration processing according 
embodiment. 

FIG. IB shows an example of the relation between ReallP Server 
according to the second embodiment 
FIG. 19 shows a system architecture of a third embodiment 
FIG. 20 shows a scenario for Standard Internet Service Registrqdja 
shown in Fig. 19. 

FIG. 21 shows a scenario for Premium Internet Service Registration in the 
shown in Fig. 19. 

FIG. 22 shows a scenario for Create VLAN Group in the structure 
FIG. 23 afaows a scenario for VLAN Group Service Registration 
shown in Fig, 1?. 



to the first 
off the VBN Server 
to the second 
and VBN Server 

n in the structure 

structure 

shown in Fig. 19. 
in the structure 



20 
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Deggriptign rftfac ftqfcrrrri ffmboflitnfflitn 
The detailed description of the invention is set out below, incli 
the best mode of implementing the invention. The description 
reference to the drawings* 



iiding a description of 
is carried out with 



The invention is referred to from time to time by its trade-mark 
and/or other aspects of the invention as the context may dictate, 
useful in muM-nnit buildings whether used as offices, apartments < 
similar accommodation buildings. It is also advantageous to ua£ 
10 seminar zooms, boardrooms, training rooms and like areas where u|ers wish to 
the network from the room. 

First Embodiment 

A VLAN implementation system according to a first embodiment vidllbe described in 
15 'detail with reference to the drawings. 



up means the server 
This invention is 
od/or for hotels or 
the invention in 



The main features of the VLAN implementation system are as follows: 

• processing of VLAN tags by the Internet access server. 

• switch filtering policies that enable one to effectively bypasi the phyaioal limit 
20 on the number of VLANs capable of being deployed 'on the switching 

infrastructure. 

• provision of secure collaborative workgroups. 

VLAN enabling of floe server of the first embodiment allows the processing of VLAN 

: 

25 tags and various VLAN services suck as: create VLAN, show VLAN, join VLAN 
Jeave VLAN and delete VLAN. 

INTERACTIVE VIRTUAL LOCAL NETWORK ( IVLAN ) 
A preferred embodiment of die first aspect of the invention -will be referred herein as 
30 an Interactive Virtual Local Area Network ( IVLAN ). 
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IYLAN is a communications technology that enables devices corns iimicatlng with the 
TCP/IP protocol (the communications protocol of the Internet) to 
and group access to any foreign TCP/IP network that has IVLAN installed, 
TCP/IP network which allows access on a temporary basis is 
Based Network (VBN), and is typically composed of care and 
route messages to and from client devices. 



gain secure private 
A foreign 
termed a Visitor 
leaf switches which 



i often. 



r.The 
lonVBNs due 



A Virtual Local Area Network (VLAN) is typically established 6n the network of 
switches to jfecilltate message traffic. Hils technology allows 
to communicate with each other and any services available via the VBN Gateway, 
capability for olients to communicate with each other is often 
to security considerations; for example, while guests at a hotel may [wish to share data 
with some other guests, it would be considered unacceptable to t 
every hotel guest registered with the hotel VBN, Since VLAN 
maintenance must typically be performed manually by a network t 
VBN systems will include at most one VLAN. 



OVERVIEW 

The rVLAN technology of the first embodiment allows for the dynamic creation of 
secure VLANs interactively by registered users of a VBN. The uaei( client) may create 
a VLAN group and grant access to other registered useis on 4 group name/password 
basis. I VLAN also allows for registered users to access VBN Gateway 'service via a 
secure private VLAN in which no other user may participate. 



i that data with 
creation and 
: administrator, most 



25 IVLAN also allows the client who creates a VLAN Croup i( referred to as 
administrator) to delete the created VLAN. IVLAN executes on a variety of operating 
systems. The preferred embodiment is based on a Linux operating iystem. 



The VLAN implementation system oomprlses: 
30 1. IEEE (Institute of Eleotrioal and Electronics Engineers ) 802.1Q Compliant 
core switch; 
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2. 
3, 
4. 

5. 
6. 



IEEE 802.1Q Compliant leaf switches; 
Custom built Simple Network Manager (SNM); 
Common Gateway Interface (COD Components 
(Hypertext Meta Language) pages; 
Registration Device Driver incorporated into the Linux I 
Modified Linux kernel Packet Driver. 



accessed 



kernel; 



EEBE802.1Q is a standard for providing VLAN identification, 
standard provides for the capability to add a "Q-Tag" to an 
message packet Information for VLAN identification is added to 
of the Q-Tag. VLANs are implemented within the switched infrastructure by using Q- 
Tags. 



Ine following paragraphs describe in mote detail the technology encapsulated by 
TVLAN in the creation, maintenance, and use of VLANs. 



PCT/CAOl/00675 



via HTML 
and 



The IEEE 802. 1Q 
net frame of a 
the frame as a part 



An example of a VBN utilizing IVLAN is shown in Fig. 1. Reflating to Fig. 1, the 
VLAN implementation system comprises VBN Server 901, core switch SO and leaf 
switches SI and S2, Clients CI and C2 connect to the leaf switch SI 
and CS connect to the leaf switch S2. The leaf switches connect the clients to the core 
switch SO. The VBN server 901 is an Internet access server. The clients may access the 
Internet 909 via Router 910 connected to the VBN Server 901. 



Each port of the leaf switch can he assigned to at least one VLAN. Client ports are 
only assigned one VLAN ID and that is the ID that they tag untagged client traffic 
with. Switch interconnect ports are tagged with every VLAN defined on that switch 
to allow VLAN traffic to traverse the switch infrastructure. In Fig.1, the olients are 
segmented into VLAN k, VLAN n and VLAN m regardless of physical location. For 
example, in the leaf switch S 1, one port is assigned to VLAN n and another port is 
a s s i gned to VLAN m. In the leaf switch S2 , one port is assigned to VLANk and 
another is assigned to VLAN k and VLAN m. 



PWX 78V140* RCVD AT 8/1W2006 4:33:10 PM [Eastern DayDght Time] « SVR:USPTOEFXiff*34 * DHB:2738»J0 « CSID:2815148332 * DURATION &nn>ss):3448 



Rug 10 2006 4:01PM 



HP IPttGROUP 



2815148332 



p- 79 



WO 01/86906 



10 



15 



20 



PCT/CA01/0067S 



-10- 



The client C3 ( an administrator) creates a VLAN group (VLAN 
Server 901. The clients C2 and C3 are registered to join M VLA> 
allows users to share files, printers, CD-ROMs and so on in a 
environment. 



filter 



Hie core switch SO forwards or filters traffic based on the VLAN 
specified in the Q»Tag. On the Core switch, the packet 
collaboration access by forwarding packets to all uplrakpoits( 
switches) that are defined as members of the same VLAN. 



identification 
enables group 
connections to the leaf 



It is noted that the untagged packet is used tocommunicate between the VBN Server 
901 end the Renter 910 and between the client and the correspo nding ! 
Between the VBN Server 901 and the core-leaf switches, the ] 
is inserted ) or untagged based on client port configuration 



COMPONENTS AND INTERACTIONS OF THE VBN SERVER 
Fig.2 shows the breakdown of the core components of the 
interactions according to the first embodiment The VBN Server 90l 
switch andthe Internet 909 via the internal 
respectively. 



m) via the VBN 
m\ Group access 
secure and closed 



pack is tagged 



leaf switch- 
(Q-tag 



invention and their 
connects the core 



25 



REGISTRATION DEVICE DRIVER(8ometimes referred to as Sob Device) 
The Registration Device Driver 904 is a pseudo driver in that! it is not actually 
associated with any physical device, The Registration Device Driver 904 manages the 
assignment of appropriate VLAN IDs for a given registration rcqujest 



30 



The Registration Device Driver 904 maintains the following information; 
• registration information Including; 

1. the VLAN ID associated with the user, 

2, the switch and port the user is connecting on; and 
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3. the VLAN group information for the user, 

driver state information including; 

1. The state information on the switches to 

configuration ohanges; and 
2- The state information for the VLAN groups. 



menage the switch 



t j _ . .• a 



Linux protocol 
'rtth the hardware 



PACKET DRIVER 

Tho Packet Driver 903 has enhanced functionality over the 
handlers at the point where the generic packet handlers interfere 
specific Ethernet drivers. 
The Packet Driver 903 handles; 

the reception of Q-tagged packets (replacing the Q-Tag header with a standard 
Ethernet header and rcconiing the tag the packet 
entry fbr that Media Access Control (MAC)); and 
the transmission of Q-taggedpackets where appropriate (replkcdng the standard 
Ethernet header with a Q-Tag header, using the appropriate! 

Broadcast packets destined fbr the internal network are treated specit Uy„ if appropriate 
a copy of the tagged packet is sent to each known VLAN(Q-Tag) t s well as sending 
an untagged packet The replication of broadcast packets is to ensujre that the packet 
is received by all systems regardless of their VLAN. 



25 



30 



REGISTRATION WEB SERVER 

The Registration WEB Server 914 is a WEB Server that serves look content for the 
VBN server 901 . This includes the Registration WEB pages, the Aehjiinistratton WEB 
pages and Configuration WEB pages* 

The Registration WEB page serves as a client's gateway to the services provided by 
the VBN Server 901. The Registration page offers the clients the opportunity to 
register for access to the Internet 910, to sign-up for group VLAN access, to create a 
VLAN group and so on. If the user elects to sign-up for an existing VLAN group, the 
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user will enter the group name and password that will be checked . igainst a database. 
If the user elects to create a VL AN group, they will be asked to pro vide a group name 
and password that will be stored in the database. The component which checks the 
group name and password against the database is referred to as Ai ihenticator 

These various servers may be hardware or software implemented 



Solsnmpd 

Solsnmpd 905 uses a proprietary protocol to accept requests and 
daemon handles communications with switches and other network 
client network using S imple Network Management Protocol (SNM P) , 
enables creation of new VLANs on switches, delete VLANs from 
remove ports from VLANs and so on* The Switch Commander u 
within the Solsnmpd which performs all VLAN operations, Motf 
Switch Commander maintains the VLAN definitions on the switch es. 



return results. This 
devices en the 
» Solsnmpd 905 
switches, add and 
the fbnotionality 
specifically, the 



THE FUNCTION OP THE VBN SERVER 
IVLAN client registration is performed via an HTML inter&oe, w^iere a client may 
interactively select to create a private VLAN, a group VLAN, or tjo join an existing 
group VLAN. If a client registers for acoesa to Internet services Available from the 
VBN Gateway, a private VLAN is established using the core-leaf switch mechanism 
for the use of the client user. 



25 
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Alternatively, the client may register to administer a Group VLAfr by supplying a 
VLAN group name and password that other clients may use to gain access to the 
Group VLAN. The group name and password are recorded by the CGI components 
that underlie the IVLAN VBN Registration HTML pages. Other clients may indicate 
upon registration for VBN services that they wish to join an existing ! Group VLAN by 
providing the group name and password for authentication. 
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During the registration process, tho CGI components communi 
through Command Line Daemon (or Sohi Daemon)de scribed bole w 
onfhe VBN Server 901. Die Solsnrnpd process issues 8NMP co; 
private and group VLANs on 

core-leaf switch system are assigned aa necessary to the created 
register for aooess. 



ommani 



i the core-leaf switch system. Common cation ports of the 

VLANs as clients 



the ability to tag 
above, the 
bs pert of die 
the addition and 



Private and Group VLANs may co-exist within the VBN due to 
message packets bb they flow through the routing system. As mentioned 
TEBB 802.1Q standard provides for capability to include a 
Ethernet ftame of a message packet The VBN Server 901 manages 
removal of Q-Tags for the message traffic of the clients , which ne sd not necessarily 
contain 802. 1Q compliant Network Interface Card (NIC) hardware, 
components obtain a Q-Tag generation ID from 
of Hie VBN Server 901 during the registration process for the 
creation. The VLAN is created as a final activity of title rcgistratioii process 



i the Registration I )evice Driver 



with Solsnxnpd 
which executes 
da to create both 



The CGI 
904 

duxpose of VLAN 



For a private VLAN ^utilized for VBN Gateway access, Ethernet frames will b e tagged 
and untagged as part of the packet routing through the core-leaf swijtch system. When 
a message is transmitted by a client, the message is untagged. The le^f switch to which 
the client is connected will insert a Q-Tag in the Ethernet frame before it is routed to 
the core switch. The message packet is routed through the core switch to the VBN 
Server 901 , where the Q-Tag is stripped from the Ethernet frame byjthe Packet Driver 
903 which executes as part of flic VBN Server kernel. The Packet {Driver 903 of the 
VBN Server 901 also inserts Q-Tags into the Ethernet frames of incoming message 
packets destined for tho client. The mapping between client and Q-Tags is based on the 
client's registration state information. 



For a Group VLAN , Ethernet Frames may or may not be tagged as part of the routing 
30 of the packet through the system. If all clients belonging to tho VLAN are physically 
connected to the same leaf switch, no Q-Tags need be inserted in die Ethernet frame 
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of the packets, Whether tags are inserted or not In this instance h 
implementation of the given switch, and is not relevant to the opeisdon oflVLAN, 
However, if clients are connected to different leaf switches within 
packets must he routed through the core switch connected to each 
instance, the Ethernet frames will be tagged before leaving the 
untagged before leaving the destination leaf switch. In Fig.1, as the 
C4 belonging to VLAN m are physically connected to the 
tagged packet is used for conimunicadon between^ VBN Server 901 
C2,C3 andC4, 



- source 



different 



I communication 



Both private and group VLANs are de-assigned from the 
switching system at the expiry of the user registration lease. The 
registration is managed by the Registration Device Driver 904. 



the system, the 
eaf switch, in this 
leaf switch, and 
clients C2,C3 and 
switches, the 
and the clients 



portBofthe 
expiration of the 



15 It is noted that "VLAN ID" or ,r VTJD " is synonymous with a Q-T$glDOdentification)- 

REGISTRATION PROCESS -JOIN VLAN GROUP SERVIC BE 
Fig.3 shows the registration process for join VLAN Group Service] The Registration 
Driver corresponds to the Registration Device Driver 904 in Flg.1. The VBN Web 
20 Server 9 14 A and the Authaxticator 914B correspond to the Registration WEB Server 
914 in Fig J, i 
Step si: The Client/Browser 915 sends data including room number, 

registration typo(VLAN group), group name and access password to 

VBNWebServw914A. 

The VBN Web Server 9 14 A passes data to the Registration Driver 
904. 

If the user's startup parameters are invalid, the event Will be logged for 
diagnostic purposes. 

Step s4: If the user's startup parameters are valid, VLAN! group name and 
30 password are sent to the Authenticator 914B for validation- 



25 Step b2; 



Steps3; 
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Stcp &8: 



Steps9: 



StepslO: 



Hie Authenttoator 91 4B queries the IP Billinj; database 920 to 
determine if the VLAN group name and password : natch. 
If a match occurred, the Authentioator 9 14B will sex d an authenticated 
response to the Registration Driver 904 , 

Upon receiving the authenticated response, the Regj; rtration Driver 904 

will send an "Add Port to VLAN Group 11 icquwt to the Switch 

Commander 917, The request will specify the VUlNID assigned to 

the group, and the switch and port to be addad to the VLAN. 

On command completion, the Switch Command** 917 will report 

ttimmFmrf status to the Registration Driver 904. 

If the command is successful, the Registration Driv<t 904 will register 

the user by sending the port and registration type to the IP Billing 

database 920. 

Registration status is returned to the VBN Web Saver 9 14 A. 



All client traffic originated or relayed by the VHN server will have £ie appropriate Q- 
Tag inserted, if applicable, by the Packet Driver based on their : egistraticm status 
before being passed through the socket interlace 918 and on [to the switching 
infrastructure 919. 

VLAN GROUP ADMINISTRATION-CREATE VLAN GROUP 
Fig/4 shows the process for creating the VLAN Group. 

Step s2l : The Client/Browser 91S sends data including room number, group 
administration coxnmand(Oeate VLAN Group), group n ame , 
aduninistration password, usage period, and user adce&s password to 
VBN Web Server 914A, 

Steps22: TTie VBN Web Server 9 1 4A passes data to the Registration Driver 904. 

Step s23: The Registration Driver 904 will send two command requests to the 
Switch Commander 917. The first command will create a unique 
VLAN group definition. The second, will add die administrator* s port 
to the VLAN definition. 
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Steps24: 
Steps25: 



Step s26: 



. For each command completion, the Switch Commmjder 917 will report 
command status to tho Registration Driyer 904 . 
If the commands wore successful , tho Registration Driver 904 will 
send data to IP Billing database 920 to register tie administrator's 
zoom number, VLAN group name , administration password, usage 

, period and user access password. 
The Create VL AN status is returned to the VBN Web S arver 9 1 4 A. 



VLAN GROUP ADMINISTRATION-SHOW VLAN GROUP 
Fig.S shows the process for retrieving VLAN group information. 
Step s31: The Client/Browser 915 sends data including room number, group 

name, administration command ( Show VLAN Group \ and 

administration password to the VBN Web Server 9 1 4A- 
Steps32: The VBN Web Server 9 14A passes data to the Regis ration Driver 904, 
Step s33: VLAN group name and administration password are sent to the 

Authaaticator 914B for validation- 
Step s34: The Authentlcator 9 14B queries IP Billing database i 20 to determining 

if the VLAN group name and administration password match. 
Step s35: If a match occurred, the Authenticatar914B will senjd an authenticated 

response to the Registration Driver 904. 
Step s36: On command completion, fbe Registration Driver |904 will send the 

query results to the VBN Web Server 9 1 4 A. 
Step s37: Tho VBN Web Server 914A responds to the dibit's request by 

sending the retrieved group information. 

VLAN GROUP ADMINISTRATION-DELETE VLAN GROUP 
Fig.6 shows the process for deleting VLAN group. It is noted thaJl "an Open VLAN 
VLID" is the default VLAN in which an unregistered part is placed. 
Step s41: The Client/Browser 915 sends data jnchiflhfl room number, group 
name, administration command (Delete VLAN Group), and 
administration password to the VBN Web Server 9i4A. 
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Steps42: The VBN Web Server 914A passes the data to the I Registration Driver 
904. 

Step s43: VLAN group name and administration password are sent to the 
Autheoticator 9 14B for validation. 

Steps44: The Authenticator 9 14B queries IP Billtog database !^0 to drtennining 
if the VLAN group name and administration p assw or d match. 

Step b45: If a match occurred, the Authenticator914B will sand an authenticated 
response to the Registration Driver 904. 

Steps46; Upon receiving the authenticated response, the Regis tration Driver 904 
will sand a" Delete VLAN Group" request to the Sy vhch Commander 
917. The request will specify the VLAN group VUD and request the 
administrator's port be removed from the definition and set back to an 
Opea VLAN VUD soft* the sofiwan tags an unregiiiered user's port as 
being a member in the Open VLAN( e.g. VLAN ID=2) . 

Steps47: On command completion, the Switch Commander 917 will report 
ooanmaod status to the Registration Driver 904. 

Step s48: If the oommand was successful, the Registration Driver 904 will 
remove tbe VLAN group definition including group name, 
administration password, user password and administrator's roam 
number from IP Billing database 920. 

Step s49: Delete VLAN group command status is returned to the VBN Web 
Server 914A. 

StepsSO: The VBN Web Server 914A reports successful or unsuccessful status 
back to Hie Client 

It will be understood by those skilled in the art that IVLAN may also execute on any 
UNIX type operating systems. 



30 



Hie functions of the VBN Server 901 are applicable to the following Internet access 
server described in U.S. patent application No. 09/742,006 (Referred to as Solution!? 
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The SohitionlP saver will be descri sod with reference 



A preferred implementation of SohitionlP™ is for the hotel industry- 
obj) ectlve is to provide guests with the ability to log into the Interapt 
rooms without having to modify their personal computer ne 



5 twurk settings 

will be able to transparently and seamleaaly get their email, surf the web, 
were in their offices. 



The primary 
from their hotel 
The guests 
i, etc* as if they 



USAGE SCENARIO 
A typical usage scenario for the SoIutionIP™ invention is shown in ^ig.7 and consists 
of a business traveler requiring access to her companies email scry :t from their hotel 
room. After connecting her laptop 101 to the hotel room's network jack 102 and 
registering for the SoIutionIP™ service, the hotel guest can access fl ie Internet, as well 
as online hotel services 104 (eg. Virtual Concierge) using the high-speed Internet 
connection of the hotel. She can then connect to the company en All server via the 
Internet at speeds much higher than possible uaing a dial-up network connection* The 
server 1 03 provides the seamless and transparent connectivity. 

i 

i 

SoIutionIP™ is a server-based solution designed to allow users to connect a computer 
with a working Ethernet Network Intarfeco Card (NIC) and an £p»based network 




via a network interface connection. Most users will have seamless connectivity, 
however there are limitations, which are described in detail below.; 

: 

, ! 

Users are required to register with the system using a browser application before 
Internet connectivity la established. The server will detect all attempts at gaining 
access to the Internet and continue to redirect users to a SohitionlP™ web she until 
registration is completed. Once registered, they will be able to use the high-speed 
Internet connection of the hotel to access corporate computing resources end email via 
the Internet, browse the World Wide Web (WWW), eto. 
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Guests attempting to pop (read ox download) their email before registration axe issued 
an email message. The message simply asks them to register ujtfng their browser 
before email can be downloaded, 



FUNCTIONAL OVERVIEW 

SolutionIP™ translates network traffic from client (hotel guest) ocWputers in such a 
way that it can be properly routed to and from the client via the hotel Internet 
connection. This is possible regardless of the current network se tings (IP address, 



that the existing 
working network 



DNS servers* gateway, etc.) on the client machine, provided 
10 configuration is functional, (i.e. The client machine must have a 

configuration, although the actual addresses used are not expected t<> be configured for 
the hotel's network). SolutionIP™ transparently translates the set ings of the client 
machine into addresses appropriate to the hotel's network environs lent while routing 
data to the Internet In addition, the server "reverse translates" reft rn network traffic 
IS to use addresses compatible with the client computer's configuration. 

More specifically, only IP-based protocols are currently supported. Other types of 
network traffic are ignored and not forwarded by SolutionIP™. SolutionIP™ provides 
DHCP (Dynamic Host Configuration Protocol) server functionality, which is used to 
20 supply configuration data to those clients configured to dynamically obtain their 

i 

network settings. DNS (Domain Name Service) requests are intercepted by 
SolutionIP™ (based on destination port number) and serviced locally by a DNS server 
running in the hotel. Outbound network traffic is intercepted by; the SolutionIP™ 
server^ which acts as a gateway to the Internet and forwards the data as appropriate. 
25 SolutionIP™ will pretend it is the client's gateway, even if the diebt has specified a 
different gateway, such as the one aonnally used by the client in the office. 
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Unauthorized use of the network (i.e, network traffic from clients who have not 
registered for the network service) is blocked by SolutionIP™ until the client registers . 
SolutionIP™ maintains a list of those client computers that have been registered and 
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are authorized to use the network. Traffic from authorized clients is Routed, while other 
traffic 1b discarded or redirected. 

Pig. 8 provides a functional block diagram of the invention j|n a typical hotel 
application. 



server 202 carries 
ismail206CPOP3) 7 



The guest 201 connects to the hotel network and the SolutionlF™ 
out the appropriate functions to handle browser traffic 205 (HTTP), 
hotel services traffic (207) (IPCTCP. UUP)) and Internet traffic 208 (IP(TCP,UDP)) 
The server 202 also provides a facility to handle maintenance trafic 209 from hotel 
services. Billing data 210 is collected and maintained in the server and supplied to 
hotel services as required 

A guest can communicate with the SolntkmlP™ server via Hypertext Transfer Protocol 
(HTTP) requests 205 (the protocol used to access the WWW), or e mail requests 206 
(POP3 ). Once registered, iP-batfed traffic originating from the guest" s computer passes 
through the SolutionlP™ server to the Hotel Services Intranet 203 or to the Public 
Internet 204. 

In general, the SolurianIP™ solution is not dlrecdy involved with Attempts to secure 
the hotel network from external threats* Creating and enforcing a security policy for 
the Internet connection of fixe hotel is to be dealt with by other components of the 
overall solution. SolutionlP™ does not perform filtering of in-bound network traffic 
destined fbr registered clients. 

The SolutionlP™ server has unnecessary services disabled and file permissions 
checked to try to prevent malicious modifications. The only login access to a 
SolutionlP™ server is by secure shell (SSH), serial connection or from the console, 
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REGISTRATION AND USAGE COMPONENT 
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The registration component is a web-based application, which allows hotel guests to 

register for the network service, as well as log offftom it It is accessible to all guests 

l 

who are connected to the network (I.e. access to the registration site is not blocked by 
SolutionIP™). The web server for the registration component car 
machine from SolutionlP™ TmnmiiHng the load on SohitionlF™. 



Prior to registration for the network service, any attempts to access 
(a type of email) servers ace detected by SohrtionlP™ and inter 
on the TCP port number. These requests axe answered by Solutwml P 
to the web server where information is provided on how to 
network service. Although this embodiment is specifically P0P3 other email protocols 
could be included. 



SolutionlP™ also has the ability to track registration information, 
for billing purposes. Currently this information is available throng! . 
web site that displays who is 
of registration, etc. The server could implement a feature to Hack <t&ta volumes. 



an administration 

i connected to the network, who is registered, time and date 



nm on a separate 



WWWandPOP3 
ted. This is based 
™ or forwarded 
for the hotel 



which can be used 



CLIENT REQUIREMENTS 
Although the system is a server-only solution and transparent to Registered clients, 

i 

there axe certain minimum requirements for client computers. SolutionlP™ is designed 
to operate without modifications to the client's compute configuration in the majority 
of oases, but certain components must be present and working. A utility could enable 
certain systems to access the network if the client does not meet the minimum 
requirements. 
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Minimum client requirements are i 

• Ethernet Network Interface Card installed and configured; with compatible 
interfeoe to hotel network jacks; 

• Installed TCP/IP stack, configured for DHCP or for static IP address, gateway, 
and DNS servers); and 
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Web browser configured for direct network access (Le 4 
browser configuration and without proxies enabled), 
regifitrati on/log-off process and 



aot a dial-up-only 
(Only required for 



The requirements described in this document are sufficient to all<j>wthe 
olients to connect easily to the Internet via hotel networking fecilii 
clients will have system configurations that will not allow connectivity through 
SolutionlP™ 



HIGH LEVEL DESIGN 

SolutionIP™ provides transparent network access via two mechanisms: 



Network Address Tramktion (NAT); Bach internal system is given a unique 
IP address to communicate with die Internet This allows ex tonal connections 
to clients and facilitates UDP based protocols as well, but will require that a 
sufficient set of routable IP numbers be available for assignment at each 
installation 

Masquerading; Bach internal system appears to the outmdd world with the IP 
address of the server* This requires special protocol-aware I 
for protocols like active-mode FT? which try po create independent return 
connections back to the client, and also modification* are made to support UDP 
"connections" (state fbll packet inspection). 



majority of 
• However, some 
the 



SolutionlP™ utilizes NAT as the primary mechanism for providing transparent 
25 network access. Despite the problems associated with IP number allocation this choice 
offers the best available mechanism to effectively deal with various unsupported 
network protocols. The preferred embodiment of the invention is based on a 
customized version of the Lanes operating system. 



30 There are two main scenarios: 
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The client is configured to use a particular, fixed IP configx jatlon. The server 
captures Address Resolution Protocol (ARP) requests froritha died and the 
server responds with its own Media Access Control (MAC) address. Hie client 
is assigned an IF address, which is mapped to the clients co: ifiguiedlP address 
and its MAC address. If Ac client has not "registered" fortlLe service, then any 
attempts to communicate with a web server or a pop serner will result in a 
redirection to die registration sewm (web) or a maUmeswige with directions 
to the registration screen. Once they have registered, the client logs off the 
registration system, their traffic is allowed to proceed imimp sded As the traffic 
passes through the server, the IP address of the client is t anslated back and 
forth between the configured (fixed) IP address and the jierver-assigned IP 
address. 

The client uses DHCP. In this case SohitionlP™'* DHCP server component 
assigns an IP address and then SohrtionlP™ acts simply as a router, except that 
normal IP traffic is blocked or redirected tmlil the client goes through the 
registration process* 



CORE SERVER COMPONENTS AND INTERACTIONS 
20 Fig. 9 shows the breakdown of the core components of the invention and their 
interactions. These components are further described below. 



25 
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ARP 

The ARP module 307 of the server uses ARP which is a standard aefworiring protocol 
the behaviour of which is described below. 

• ARP (Address Resolution Protocol) (See RFC-826 (RFC stands for Request 
For Comment and is the standard way of asking for co mmen ts on standards and 
other aspects of Internet operation via the Internet A website that is useful in 
accessing the various RFCs is www.faqs.com)for the protocol specification) 
is i n te nd ed to provide a method for one machine * n obtain the MAC (Media 
Access Control) Address of a system for which they know the IP address. 
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information* 



that they wish to 
the IF address 

If the mflgfrin* 

currently there is no 
a MAC address 



a] id i 



l ARP request for the target m* shine's IP address 
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Typically, a machine will determine that the machine 
communicate -with is on the same local network by 
of the target machine with their own IP address i 
they want to communicate with is on the same network, 
association between the IP address of the target system 

tliftn flifl machine will rafllra an 

If the target machine is active, it should be watching for ARP requests and if 
the IP address specified in the ARP request matches the IP a idrcsa of the target 
machine it will respond to the ARP request 

The address resolution protocol is a protocol used by the Int atnet Protocol (IP) 
network layer protocol to map IP network addresses to the I aidware addresses 
used by a data link protocol This protocol is used below the network layer as 
apart of the OSI link layer, and is used when IP is used over Ethernet 

The term address resolution refers to the process of findiilg an address of a 



computer in a network. The address is "resolved" using a protocol in which a 
piece of information is sent by a client process executing on he local computer 
to a server process executing on a remote computer. The inl situation received 
by the server allows die server to uniquely identify the network system for 
which the address was required and therefore to provide the required address. 
Hue address resolution procedure is completed when the client receives a 
response from the server containing the required address. 



25 
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F*oxy-ARP (See RFC -1009 for a description) is a variation on the ARP 
protocol where a router (a system with more than one interface that routes ' 
packets between networks on or through the networks on each interface) will 
respond to ARP requests for systems on one interface made by systems on an 
other interface with it's own MAC address. Tins is done to support situations 
where it is necessary or expedient to split a network without sub-netting or 
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i 

whore machines not capable of understanding sub-nets {have to reside on 
sub-netted networks, 

SolutionIP modifies the standard behaviors described above on an 
5 interface-by- interface basis by promiscuously responding to ARP i ©quests. This is an 
extension to Proxy-ARP. In general, any ARP request is responded to by the 
SolutionIP Server with the SolutionIP Server's MAC address regardless of the IP 
address being requested, with the following exceptions: 

L Microsoft windows and some other OSs, while booting, will send an ARP 
10 request for the IP address that their interface is configured for 3 and if they 

receive a response (hey will shut down that interface mi not attempt any 
network activity. This is a lest to ensure that the 

system is unique and avoid Conflicts. These test pad Gets have unique 
characteristics that allow the SolutionIP server to recognize them and not 
IS respond to these requests* j 

2* IftboARP request is for a system for whkhthe SdutionIp|eivBrhflaancnti7 
in the registration driver, then it is left up to that system to rUpond rather than 

the SolutionIP Server. i 

i 

3. In the case where the SolutionIP Server needs the MAC [address for an IP 
20 address it will first determine if an entry exists in the registration driver end If 

it does use that MAC address rather than sending an ARP Request 



25 



This allows the SolutionIP server to pretend to be the gateway (defeult router), DNS 
Server, etc* foe clients using fixed IP configurations. In addition,! the server avoids 
delays when communicating with systems on its client networks by using the 
registration driver rather than making ARP requests. 
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REGISTRATION DEVICE DRIVER (sometimes referred to as Soln Device) 
The registration device driver 304 is a psendo driver in that it is not actually associated 
with any physical device but rather the device is the registration data that is stated and 
managed by this driver. The registration information maintained by the driver includes: 
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Original IP - this is the original IP address that the client used when 
communicating with the server. Under certain circumstanc eg, it may be equal 
to the assigned IP addness, A fixed IP configured client will iave the IP address 
for which the client is configured. For a DHCP configured client this will 
usually be zero or the IP address that the client was assigi ie d on its previous 
network or it will equal the assigned IP addresa 

Assigned IP - this is the IP address assigned to the client by the registration 
server. This will be a number chosen from the available IP addresses in the 
address ranges flat the driver is configured to support An IP address is always 
assigned to each new MAC address as it is encountered. If the original IP 
address is equal to an unassigned IP address that the driver his bean configured 
to support then that IP address will be assigned, otherwise the next available 
IP address will be offered. 

MAC address - this is the MAC address of the client systet a. 

Creation Time - is the time that the IP address was assigned to this MAC, this 

happens when the first packet is received from tho client ! 

Registration Time - is the time that the client was registered (for Internet 

access) by going through the registration process for that site. 

Registration Expiry - is the time (hat the registration is dire to expire (lose 

Internet access). 

Entry Expiry- is the time that the assigned ff address will be retomed to the 
pool office DP addresses. 

Last Used - tho lost time there was traffic to/from the client-system. 

Flags - used to contain, bit fields used to indicate the state and nature of a 

particular client (Le. registered; DHCP; valid; permanent; np expiry; etc.) 
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This infiwmation is accessed and manipulated by other kernel drivers and processes 
through function calls defined in Registration Device Driver 304. User space 
applications access and manipulate thg registration information with Ae standard Lane 3 
device interface and the associated toed calls. Entries can be looked up using original 
IP, MAC, or Assigned IP addresses. All characteristics of an entry can be manipulated, 
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altboughnot all directly, an entry ean be marked as registered and tfaje driver will assign 
the expropriate registration expiry time. Certain attempts to lookup anentry will result 
in an entry being assigned if an existing entry can not be fount, specifically the 
sobi jgetjaipjnac call will cause an IP address to be assigned to the specified MAC 
5 address if an existing entry can not be found, A complete dump of die current state of 
the driver can be obtained by opening and reading the device. Likewise, this 
information can be used to initialize the driver by opening the dev oe end writing the 
same (or similar) information back into the device. This gives us the ability to backup 
and restore the current state of the driver thus minimizing the efleets of reboots on 
1 0 registered clients. In addition to the information described above th 9 state information 
for the driver includes: 

• How often the driver's current time is updated (time granu arity). 

• How often to run the purge algorithm that looks for register* «i entries to expire 
and to for unregistered entries to be purged. 

IS • What the default expiry mode la for the system this can include one of the 
following: 

0. NO JBXPIR.Y - where no entry is ever coqrfred automatically. 

1. ElBLATIVE_OFFSET_BXPlRY - where entries are expired a fixed amount 
of time relative to the time that they registered. 

20 2. TIMEOFDAY_EXPIRY-where entries ate expired at a! particular time of 

day regardless of when they registered 

• The expiry period is either foe time ofiEset for the relative bfifeet mode or the 
time of day for the time of day mode depending on the expiry mode chosen* 

• The time of day grace period, this is used to determine if the second time of 
25 day expiry should be used rather than the next In other woidlsifthe time of day 

expiry time is 1 1 :00am and the grace period is ft hour then if someone registers 
between 10:30am and 11:00am they will actually be registered until the 
following day rather than just being registered for V£ hour or less. 

• The inactive timeout which is used to decide whether to expire a unregistered 
3 0 entry, in essence if activity has been detected for an entry within the inactive 

timeout period then the entry will not be purged. 
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The number of ranges available for assignment to clients, ! 

• The range data, each ranga is specified by a starting IP adc ress and an ending 
IP address the IP addresses must be of the form A~B.Qx az d A.B.C.y where 0 
<- x o- y <- 255. Thus each range may consist of up to 256 entries, this 

5 allows multiple ranges to specify a network larger than a cjlass C subnet. 

i 

In addition to externally triggered events, the registration driver has cert erin automat ic 
activities that it performs on a regular (configurable) basis: 

• If the current time is older than the l^lstraticm expiry time if an entry then the 
1 0 driver will unxegister that entry, unless that entry is marks i as no expiry. 

• If Ac current time is older than the entry expiry time of an e itry then the driver 
will purge that entry (return the assigned IP to the pool of available assigned 

IP addresses) unless the entry is marked as permanent 

* 

• The registration driver updates its concept of what the cun dot time is. 



TCP/IP SOCKET INTERFACE j t 

The TCP/IP Socket luter&oe (311) is the standard socket networking inte rfa ce 

provided by Linux, Unix, and many other operating systems that provide networking 

services. 



COMMAND LINE INTERFACE/Boln Daemon 

The Command Line Interface 317 offers an administrative and diagnostic tool to 
system administrators. It serves as a user space interface into the registration driver. 
It has options for most of the Registration Driver's ioctls. It can be used to check the 
25 current state of the registration driver 304 or modify it. 
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The Soln Daemon 3 15 shares the same code base as the Ccmimand Line toterfece 317 
and thus shares much the same functionality. It is launched from the Command Line 
Interface using a command line parameter that forces it to run as a daemon. As a 
daemon, it has several special functions. It is responsible for performing regular 
periodic backups of the registration driver. It also listens for HDP traffic ana specified 
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port This facilitates most of the registration and administrative requirements of the 
web based interface. It is also able to communicate with Solatia pd ( a module for 
carrying out network management) and retrieves information as required during a 
registration request 

i 

5 ! 

! 

IPFW/tpftoadm/Packet Filter Rales 

The packet filter module 305,306 allows packet filter rules that test the state of the 
registration entry flags for the source and/or destination addressee of packets! these 
tests include; 

10 « tests far whether the address is a valid entry or not (Le. is it ia a valid tango and 
has it been assigned to a MAC address); 

• tests for whether the address is a DHCP entry or not; and 

• tests for whether the address is registered or not 

1 5 Ipftvadm, the standard L izxux utility for defining the packet filter rule s in the kernel at 
run-time has been modified to set and interpret the new tests as specified above. 

Packet filter rules are defined to provide the following fimctionalit^ : 

• unregistered clients' POP requests are redirected to the SolutionlP custom POP 
20 server; 

• unregistered clients' HTTP requests are redirected to the redirection web server 
3 1 4 that is configured to redirect requests to the registration web server 3 1 0. 

• All clients* DNS requests ore redirected to the local DNS server 312. 

• All other unregistered clients' requests are blocked 

25 • All registered clients' SMTP requests are redirected to the lical SMTP server 
not shown). 

• Where unroutable addresses are used for clients the filters can be configured- 
to perform masquerading or NAPT (Network Address Port Translation). 

• Other filters can be configured to provide security for the SdlutionIP server or 
30 to block client access to specific arbitrary protocols. 



PAffi 98/140 * RCVD AT aiW2006 4:33:10 PM [Eastern DayDght Time] 4 SVR:USPTO€FXIff -6/34 1 DHK:2738300 J CS1D:281 5148332 * DURATION (mifrss):3448 



flug 10 2006 4s06PM HP IPttGROUP 



2815148332 



p, 99 



WO 01/86906 



PCT/CAO1/0O675 



-30- | 

PACKET DRIVERS 

The packet drivers 303 have enhanced functionality over the standard Linux protocol 
handlers at the point where the generic packet handlers interface {with the hardware 
specific* Ethernet drivers. This additional functionality is selectablcj 
5 basis. 

On an enabled interface, all Incoming packets are examined, and flu it MAC looked up 
in the registration driver. If the packet is an IP or ARP packet then the MAC is looked 
up in the registration driver, if this is the first time that this MAC ii; encountered then 

10 an IP address is assigned end if the source IP address of the packet is a valid 
ucassigned IP address then that IP address will be assigned to that AC address. Once 
the assigned IP address is determined, sanity tests are applied to ensiite that the original 
IP address associated -with the MAC has not changed in an unaccq table manner, if it 
has changed in an unacceptable manner then the entry is deleted, thu 9 forcing the client 

15 to re-register if they were previously registered. If the assigned IP c ddress is different 
from the original IP address in the client's packet then that LP address will be replaced 
with the assigned IP address in the IP or ARP header and the packet checksum 
recalculated according to the methods described in RFC- 1624. If the packet contains 
aTCP or UDPpacketthen the checksum is further recalculate 

20 the change*! IP address in the pseudo-header associated with such packets as described 
in section 3.3 of RFC-1631. 



All outgoing packets on an enabled interface have their source destination address 
looked up in the registration driver (as an assigned IP address). If a m*ft^ine entry is 
25 found then the original' IP address is substituted provided it is nonzero and not equal 
to the current destination address. Then the packet^ checksums are recalculated as 
described above for incoming packets. 



DHCP SERVER 

30 A modified DHCP server 3 16 has been included in SolutionIP to provide IP addresses 
to clients requesting IP information based on th* assigned IP addreas provided by the 
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regtotion device driver 304 for that client's MAC address. Additionally the DHCP 

j 

server 316 has been modified to provide leases based on the inactivity timeout as 
obtained from the driver. 



10 



15 



20 



25 



POP SERVER 

A modified POP server 313 is provided to: 

• accept any useraame and password combination; 

• ignore all mailbox-modifying commands; and 

• present a special mailbox with a single new site-specific message as Ilia only 
available mail. The intention of this message is to direct tl l6 user to use their 
web browser to access the web so they can register for the service. 

Normally POP ( a request to read or download mail from the cli arts email server) 
requests from clients would only be directed to this server if the oln^tia attempting to 
access their e-mail without being registered. 

SMTP SERVER 

A MTA (Mail Transfer Agent) has been configured to : 

• Act as a mail gateway for clients. Many sites configure thfeir mail servers to 
block outsiders from sanding mail through them to another she. This is a 
security precaution against spammers using a site as a reliy. We redirect all 
clients SMTP trafH c to our local server so clients will be able to send mail as 
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* The SMTP server (not shown on Fig. 9) is configured to block relaying 
attempts using the SohxtionlP server. 

REDIRECTION WEB SERVER (solhttpd) 

The firewall rules redirect all unregistered traffic on port 80 (http) to a special port on 
the SolutionlP server. The solhttpd daemon is a web server 314 configured to listen 
for http traffic on a special port When it receives an http request, it is configured to 
rewrite the URL such that it will send the client to the Registration WEB Server 310. 
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This means that any unregistered client who launches their standard web browser will 
be redirected to the Registration WEB Server instead of their intended destination. 
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REGISTRATION WEB SERVER 

The Registration WEB Server (3 10) is a web server fbat serves loi >al content for the 

SolutionIP server. This includes the Registration WEB pages, Administrative WEB 

i 

pages, and Configuration WEB pages. 



REGISTRATTON/ADMINISTRATION/CONFIGURATION WEB 



The Registration WEB pages serve as a client's gateway to S olutioifP 
includes registering for access to the Internet Tho client can choose 
different methods of authentication, port based or access code based 
authentication model, a client's room and fee information is determined 
their assigned IP address (facilitated by Solsnmpd). In acfeass 
authentication, clients can enter access codes that map them to 
number and fee. 



PAGES 

services. This 
between two 
In the port based 
bhflcd upon 
code based 
particular room 



In addition to the registration side, there is also an administrative set of pages. These 
pages allow server administrators and staff to perform various taaik These include: 

• the checking the current state of the registration driver; 

• manual registration changes; 

• modification of registration driver settings; 

• modification of Soln Daemon settings; t 

• display system health variables: 

• display of billing information; and, 

« the display and generation of access codes. 
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The registration WEB pages use the Soln. Daemon (315) to communicate with the 
Registration Driver and Solsnmpd to facilitate administration and the registration 
process. 
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Also provided are several first generation web based configuration tools. Primarily, 
these are designed as middleware to insulate the users from the diabase. 



BILLING DATABASE (Ipbflling) 
A standard open source relational DBMS (database management system) implements 
a schema designed to support the billing process. The schema allows flexible 
configuration of the system and Includes the following: 



• site configuration information; j 
10 • fee information; 

• network infrastructure and associated mappings, including room to port 
mappings and other switch-related information; 

• billing and usage information; and 

• access Codes. 

15 

DNS SERVER 

A standard open-source DNS server 312 is provided to aU clients to handle their DNS 
requests. There is nothing special about this server; rather what is special is that all 
client DNS requests axe directed to this server. This ensures that bo client (static or 
20 DHCP) will have its DNS requests timeout because the DN$ server is either 
inaccessible (behind a firewall) or to o fer away (too many network hops) to respond 
in a timely manner. 



Sobnxnpd 

25 This server uses a proprietary protocol to accept requests and return results. Request 
and response packet formats are define d as needed fbr each query. Thfi purpos o of this 
daemon ia to handle communications with switches and other netWork devices on the 
client network using Simple Network Management Protocol (StNMP) to achieve 
various ends. The initial functionality for fids daemon is to accept requests to 

30 determine at which "physical port" a client is ooxmeoted. The daemon is sent a request 
containing the MAC address of the client The daemon then uses the switch hierarchy 
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as defined in the billing database to walk through the switches usnjg the Biidge MIB 
(RFC-1493) to determine the what port the client is connected tjhrough. Once the 
switch and port are determined then the "physical port* can be dativ ?d, again using the 
billing database* This information is returned to the requesting process. 



aden 
allow 



nil ting 



from the billing 
access of the 
configuration 
so they will 



Solsyncd 

This .server (not shown in Fig. 9) extracts configuration inform 
database and places it in flat (text) configuration files to 
configuration Information without accessing tibe database* If theresi 
10 files have changed then a HUP signal will be sent to specific 
re-read their configuration files and get the updated data. 



PROCESS MONITOR (keepallve) 
This script is run every minute and 1 s configured to check the status of several daemons 
15 on the server, complain if they are not running and if they continue to not run for a 
configurable length of time they are restarted. 



20 



SERVER CONFIGURATION TOOL (reconflg-alLpl) 

This tool takes a per*ite configuration file and applies it to a hierarchy of template 

configuration files to configure die server for a particular site. 
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From the above description is recognized that net all components have been shown of 
Fig. 9 but a person skilled in the art would understand how the functionality described 
by the components not shown would be integrated into the system, it canbe seen from 
the above description that the term server is used both to refer to a bomputer running 
the programs to achieve the desired functionality gad to software modules themselves 
that carry out the desired fimctionality. It is understood that therelis a continuum of 
structure and various aspects of the invention can be carried out by hardware, firmware 
or software, or a combination, as may bo desired. 

SERVER PROCESSING 
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The following sections describe various processing carried outbyflje server in general 
terms. 
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DHCP REQUEST PROCESSING 
The processing performed by SohrtionIP™ far DHCP requests is ^escribed below in 
reference to Fig. 10. I 

When a guest with a compute configured for DHCP powers on, the computer 401 
initiates a DHCP request to the other computers on the LAN. Th * modified DHCP 
server 405 receives and processes that request The DHCP serve • 405 captures the 
MAC address of the guest computer 40 1 and initiates a request for e tt IP address to the 
Registration Device Driver 404. The Registration Device Driver provides an 
appropriate IP address for the guest The IP address is returned to the DHCP server, 
which then passes the address and any additional parameters (gateway to use, DNS 
server to use, etc.) back to the guest's computer. 

i 

i ; 

i 

ARP BEQUEST PROCESSING 

The processing performed for an ARP request is described with reference to Fig. 11, 
below. 

To identify exactly which machine on a LAN has a particular IP address, a guest's 
computer 501 initiates an ARP request, asking for the MAC addrcjss of the machine 
having the specified IP address. The Registration Device Driver 5 04 detects the ARP 
request end responds with its own MAC address via the ARP server 505, regardless 
of the IP address actually requested. While processing the ARP (request, the ARP 
server 505 will notify the Registration Device Driver 504 of the guest computer's MAC 
address and IP address. The Registration Device Driver 504 can tfren determine if a 
matching MAC address and IP address pair exists, as well as whether NAT will be 
required for the guest computer. The Registration Device Driver 504 will then update 
its data structures with the new information if necessary. 

UNREGISTERED HTTP REQUEST PROCESSING 
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Processing of HTTP requests involves redirecting unregistered guests to the 
registration web server, and allowing requests from registered quests to be routed 
normally. Processing of unregistered HTTP requests is described i s shown in Fig. 12. 



Processing of a Hypertext Transfer Protocol (HTTP) request begins with receipt of the 
request by SolutionlF^s packet driven 603. These drivers quay the Registration 
Device Driver 604 to identify whether NAT translation, of the packet headers is 
required. If required, the packet drivers 603 perform this translation. The IPFW 
component 606 is then given control of the request. It queries the F egistration Device 
Driver 604 to determine whether the guest is registered. If the gusfcrt is registered, it 
allows the request to be routed normally. If the guest is not regis* xred, the request is 
passed to the Redirection Web Server 608, which translates it into a request for the 
registration area of die Registration Web Server. The translated request is then 
submitted to the Registration Web Server and the guest is present & with the hotel's 
registration screen. If the guest chooses to register for the network iiocess service, this 
information is provided to the Control Program/Daemon, which updates the 
Registration Device Driver appropriately. Subsequent requests from the guest 
computer following the update of the Registration Device Driver will be processed as 
from a registered guest. 

REGISTERED HTTP REQUEST PROCESSING 

The following description is made in reference to Fig. 13. The general processing 
performed by the SohitionIP™ server for IP-based traffic other than web and email 
traffic is the same as shown in Figs. 12 and 13 except that it'ia not subject to 
redirection, IP-based traffic initiates fiom the guests computer 701 and is sent to the 
SolutionIP™ server. The packet drivers 703 ontheSolutionIP™ server then determine 
whether the traffic requires NAT and performs translation on the headers if so required. 
The IPFW packet filter 705,706 then determines whether the guest has registered for 
the network access service. If the guest is registered, the data traffic is allowed to 
proceed and routed normally. If the guest has not registered, the data is blocked by 
discarding the incoming network packets. 
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BILLING ASPECT OF INVENTION 
The following section describes the components and functionality of the billing aspect 
of the server and method invention. 



The billing aspect of the invention has two methods of registration 
port identification. Access codes are generated for each room on a 
must enter the access code for their roam as port of the registration 
identification will automatically determine the client's room numb sr by 
network switch infrastructure to determine the specific switch port 
client is connected. Switch ports will be mapped to specific rooms, 
be used in the event the client is not connecting from a guestroom, 
working from a public area in the hotel, or if the switch port canru t bo 



Authorization codes ere used as an override mechanism to apply special processing 
rules (discounts, free usage, etc.) to particular clients- The system iitoics and displays 
the authorization oodo as part of the billing report. The interpretation and application 
of authorization codes is the responsibility of hotel staff. 



access codes and. 
daily basis. Clients 
process. Port 
querying the 
from which the 
Access codes can 
such as when 
determined* 



The hotel Property Management System (PMS) performs the actual billing of clients, 
20 The billing system provides web-based reports which can be prikted and manually 
entered in the PMS by hotel staff. 



REQUIREMENTS 

SolutionIP requires two Pentium class systems operating at 200 KtHz or greater. One 
25 Amotions as the SolutionIP server while the other hosts the web site and database. 
These tvmrJdngg require the following hardware: 

• 64MB RAM; 

• 4.5GB herd drive; 

• Network Interfece Card (NIC) (Linux compatible) NOTE: The SolutionIP 
30 server requires two NlCs and the web server requires one; 

• Monitor and keyboard are optional; and 
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Tw© serial ports. 



10 



The client component has the following requirement*: 

• Network Interface Card and connector: 

i 

• Web browser, 

• TCP/IP stack; and 

• A printer connection will be required for billing reports. 

SolutkralP supports a variety of client operating systems includiig Win95, Win98, 
WinNT, Macintosh OS 8 and Linux. 



The switches for port identification must support: 
• Bridge MIP (RFC 1493); 
9 SNMP read access; and 
15 • 1-1 mapping (room to port). 



■ 20 



25 



The software requirements are based on the functionality of each n^achine: 

• SolutionIP Server; 

Operating System -RedHat Linux 5.1. 

• SolutionIP Web/E>*tabase Server: 
Operating System - RedHat Linux 5.1; 
Web Server - Apache; 

Database - PostgreSQL 6.4 or higher, and 
Perl 5.004. 

It is understood that the aforementioned components are for the prefefred embodiment. 
A person skilled in the art would recognize that other components could be used 
without departing from the invention. 



30 



AREAS OF FUNCTIONALITY 
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i 

Thxe* main areas of functionality exist for the billing system, jrhese include port 
identification, access code generation and interpretation, aid billing system 
administration. This section presents an overview of the general requirements of the 
system, as well as the specifio requirements for each of the areas jrf functionality. 

! 
i 

i 

OVERVIEW OF BILLING 

Billing begins with the identification of the room associated with < sach client. Roams 
are identified either manually by associating an access cade with a particular room, or 
automatically by obtaining me switch port the client is connected :o and deriving the 
associated room. The system provides fecfllties to automatically gei lerste a new access 
code for each room, either for the current day or too next day- The c odes are displayed 
via a web page and can be printed. A configurable history <f access codes is 
maint ained to prevent duplicate codes from being generated within the history period. 
No mec hanism is provided to prevent access codes from being uspd more than once 
or by more than one client Each new MAC registering is billed to the associated room. 
Registrations will be valid until the next checkout time. The access code is used to 
determine which room to bill, and so it will be the responsibility ofthe client to ensure 
that the code is kept secure. Billing is based on the room from which the client 
registers when using port identification. 

Once the room is identified, the fee associated with that room wffl; be determined. A 
flat foe per day will be associated with each room (different rates can be charged for 
different rooms). The registration interface allows clients to enter special authorization 
codes. These codes wfil be stored with the client's billing information. Authorization 
codes used will be Inclnded in the billing report generated for hotel: star!, but will not 
actually affect the fee generated by the billing system. Interpretation and application 
of autiorization codes will be the responsibility of the hotel staff 



30 



A web-baaed billing report is provided and printed by the hotel staff. It displays who 
has been online since the last checkout time. Additional queries for arbitrary dates is 
also available. These show who was online from checkout time on foe specified day 
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until checkout time the next day. Information included in the 
room, registration time, access code, part, authorization code, 
administrative web reports are password protected. 




PCT/CAOl/00675 



includes client 
fee. Access to all 
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Tile database is capable of storing one month's worth of data. Backjup, restoration, and 
disaster recovery procedures can be provided* 



PORT IDENTIFICATION 

One method of associating a client (MAC Address) with a Room for 
is Port Identification, I£ on registration, the physical port oonnecti m can be 
as being associated with a room, then that client's registration w U 
room. To determine what physical port a client is connected to tie 
Management Protocol (SNMP) is used to discover which switch p dit they 
to, static data tables are then used to determine the room number* 



The switoh/port numb er that a MAC is us ing is determined by using SNMP to seaich 
the installation's switches. 



billing purposes 
identified 
be billed to that 
Simple Network 
are talking 



Mapping ftom the switch/port number that a MAC appears on identifies physical ports. 
20 This mapping is maintained in the database 

Physical ports map to room numbers and billing rates. These mappings are maintained 
in the database. 



25 The determination of die MAC to physical port mapping is done on an as required 
basis. 



30 



If port identification is available it takes precedence over access code identification and 
no access code is requested of the user during the registration process. The exception 
to this are physical ports flagged as requiring a vaiid access code for registration to 
succeed. 
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ACCESS CODE IDENTIFICATION 

An alternative to Fort Identification is Access Code Identification Bach access code 
is associated with a particular room and will be valid for a limited ti m<5 perio d (usually 
one day from checkout time to checkout time). If port identifies ion Mis or is not 
available on a given port then the client will be promptod for an acc »3 code which the 
system then validates. This will ensure that a billing record is generated for the 
appropriate room. 



10 
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ADMINISTRATIVE FEATURES 
This section of the specification describes the administrative featured related to billing. 
The administrative features serve as the interface between the bilU tig system and the 
hotel stafE The two main components are the billing and access code reports. 

BILLING REPORT 
The billing report provides information to the hotel staff regarding room numbers, 
access codes, authorization codes, physical ports, registration time a: id foes. The report 
is web-based and viewable from a standard web browser. The hottl staff are able to 
generate and view the report on an as-needed basis. 



20 ACCESS CODE GENERATION AND REPORT 

The access code report provides hotel staff with the information related to room 
numbers and access codes. The report is web-based and viewable ftom a standard web 
browser. The hotel staff an able to generate and view the report an an as-needed basis. 
Upon reviewing a report; the system automatically generates access codes for the 

25 current or the following day if they do art exist in the database. 



FUNCTIONAL COMPONENTS 

The following section describes the functional components of the billing system and 
refers to Fig. 14. It is to be understood that the preferred embodiment here described 
30 uses two computers acting as servers but a person skilled in the art would understand 
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that one server could be used or more than two could be used without departing fiom 
the invention. 
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OVERVIEW 

i 

The billing system consists of components running on bom the SoIutionIP Server 802 
and the Webserver 801. The Webserver hosts the billing end conf guration database 
803. the Admin Intet&ce 804 which will be part of the Admin web site and the 
Registration Interface 805 which will be the existing Registration t Web pages with 
modifications to accommodate the new billing system methods. (In the SoIutionIP 
Server the Registration Driver 806 and Command Line Daemon 8( 1 accommodates 
the new billing system methods. The Synchronization Daemon 808 and the SNMP 
Daemon 809, are implemented to support the billing system. 

DATABASE 

The Billing System in the preferred embodiment is implemented using a PostgreSQL 
6.4 database. The database stores configuration information, access i sodes, and billing 
records. One month of data will be maintained at any grventhne.Dte^ 
month will be regularly purged fiom the database. Database backup and recovery 
procedures can be provided, required. 



t information 

(switoh addresses, types, mappings of switch ports to rooms, eta). Hotel checkout 
time, amount of data history to maintain, and other related parameter will also be 
stored in the database. 

The database states the access code and its ef^ve dates for each room. By defiw^ 
each code will only be Active for one day. Ahistory of access codes for each room 
is kept New codes are checked against this history to prevent duplication. 

Billing records identify the room to be billed for each connection. The following fields 
win be included in this record: 
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roam number; 
port registered from; 
access code used; 
authorization code; 
registration date and time; and 
type of fee to be charged. 



10 



15 



20 



In certain cases, some fields may be NULL. For example, the Recess code would 
normally be NULL when port identification is being used. 



requests 



COMMAND LINE DAEMON 

The daemon has the ability to handle multiple simultaneous 
systems, preserve parameter changes and track the state of registration driver backups 
The daemon also accommodates the use of the SNMP 809 
daemon 808. 



and 



from other 
er backups. 
Synchronization 



REGISTRATION DEVICE DRIVER INTERFACE FUNCnjoNS 

The Command Line Paernon 807 is the primary interface into the Registration device 

driver 806. The functionality of the registration device driver accominodates the billing 

system 



The command line daemon supports the following operations : 

• net the original room and port Id for a specified user; 

• set the current room and port id for a specified user; 
25 ♦ . block a specified user, so they can not register, 

• unblock a specified user, so they can register, 

• flag a specified entry as permanent; 

• flag a specified entry as no longer permanent; and 

• x ?ct a graco period (time period prior to checkout, during which registrations 
30 will not expire until checkout time the next day). 
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INTERFACE TO SNMP DAEMON I 
Hie billing system oomnrnnicatca with fee SNMP Daemon SWviai the Command Line 
Daemon 807. The Command Lino Daemon 807 channels all trafiijo between the other 
billing system components and the SNMP Daamnn Thftr rttmwaiilf TfarPnmpnnlno 
5 updates the Registration Device Driver 806, where applicable, withjtheresults received 
from the SNMP Daemon. 

' ! 

; 

j The command line daemon : 

• responds to requests for port id resolution ftom both the regulation server and 
10 kernel driven; 

• forwards requests for port id raolutio n to the SNMP Daemon; 

• receives port ids back from the SNMP Daemon; 

• passes port id information back to requestor; and 

• infonwtheJcenidofport 
15 the transaction. 

SNMP DAEMON 

The purpose af the SNMP Daemon 809 ia to resolve MAC addresses to flieir physical 
port number, or return an otot if this is not possible. This Daembn uses SNMP fa 
20 interrogate the network switches to fi^ the switch port that the cU^ is connected to 
and then use static data tables to map that switch port to a physic* port numbecj^ 
this component: 

• configuration data ia obtained from flat data files stored <m the SolutlonIP 
25 Server; 

• configuration data files will be derived from database tables andupdated by the 
Synchronization Daemon; 

when Configuration files are changed the SNMP Daemon will be informed by 
the Synchronization Daemon; and 
30 • requests and responses are handled through standard Interprocess 
Communication Metho da to other components on the system. 
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I 

REGISTRATION DEVICE DRIVER 

i 

The Registration Device Driver supports billing and production requirements. The 
driver maintains information on client MAC addresses, original EP addresses, and 
assigned IP addresses. Timing parameters are included to allow fixed-length 
registration periods, as well as inactivity timeouts for unregistered ollents. A Time of 
Day expiry mode is included. The method of expiration will be dot armined at the time 
of client registration. Under the Time of Day expiry mode, registn tions will expire at 
me next checkout time (or any arbitrary time each day). Currently ru :w registrations are 
expired nt the end of a fixed time interval, typically 24 hours. The ' 'fine of Day expiry 
mode is more consistent with normal hotel billing routines. T io existing expiry 
calculation mode will be preserved as an option. 

In addition to the new expiry mode, the ability to override parameters for individual 
clients is available. Existing driver parameters serve as defaults, arid affect all clients. 



30 



An overide mechanism allows administrators to change specific parameters on a 
client-by-oHent basis. An example might be to extend the expiry time of a particular 
client, without affecting the expiry times of other clients. 

In addition to operating on MAC and IP address rnfbrmation, the driver includes and 
operates an room and port data. The work of associating rooms and ports with clients 
in the driver is performed by external components (the biUing system and SNMP 
daemon). Operations supported by the driver, such as registering or deleting entries, 
allow such operations to be performed on all clients associated with a particular room 
or port. 

Production requirements inolude the ability to reserve specific addresses or make 
entries permanent. This allows support maintenance access to network devices, such 
as switches, which reside on the client aide of the servers. A mechanism to block 
particular clients is also implemented. This mechanism identifies clients by room, port, 
or MAC Blocked clients are able to access the registration server and other services 
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j 

available to unregistered guests, but they ate prevented from registering for full system 



access. 



SYNCHRONIZATION DAEMON 
S The purpose of the Synchranizatioii Daemon 808 is to centralize access to the ^ftifrflp* 
by components of the SoIutionlP Server through one interface. *jrhe daemon uses 
information stored in the database to create flat configuration files on the S olutionIP 
server. This allows configuration information for the various Components to be 
centralized in the database hut does not preclude their mug mainti i\ttfx\ m thg mrym 
10 if a database is not available or required at a particular installation 

When files are updated by the Synchronization Daemon, the processes that use them 
are informed that an update is available (methods of communicating this include 



signals, IPC semaphores or having the process monitor the last mjadified time of its 
IS configuration files). It is also possible to have this process update Information in the 
database based on status files from the Solutionis server. 

WEB SERVER REGISTRATION PROCESS 

Hie registration process takes advantage of the hilling system methods. When a client 
20 attempts to register, the system first attempts to determine if they arb connecting from 
a zoom that allows billing via the port identification method. If a billable room is 
identi fie d using this method then the user will be presented with the Authorization - 
Confirmation Screen. If a billable zoom cannot be identified using the Port 
Identification Method then the Access Code Identification method! will be used. The 
25 user will be presented with an access code entry screen, when the user enlera a valid 
access code then the billable room will have been identified and the^ will be presented 
with the Authorization - Confirmation Screen. The Authorization - Confirmation 
Screen will present the user with the zoom number and rate and anjy other important 
info r mat i on. The user will also be given the opportunity to enter an optional 
30 Authorization Code. Once the user confirms their willingness to pay the specified rate 
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they will then bo taken to The Virtual Concierge. This allows one 
of services offered through the hotel as well as the www and emait 



to access a variety 



PARTICULAR USER EXAMPLES 

To better understand the operation of the invention a number of specific oxmples 
follow that explain in detail the step s carried out by the invention in order to achieve 
the results desired in the particualr scenarios set out. 



CLIENT STARTUP 

SYSTEM STARTUP 

Scenario: Client boots their computer. 



FIXED IP 

! 

15 Scenario: Client is configured with a fixed IP configuration, 

1. Client turns system on, 

2. System generates an ARP request to see if its IP address is Already in use. 

3 . SohrtionIP server picks up the ARP request and passes it to {he Packet Driver, 

4. The Packet Driver asks the Registration Driver to look u£ the Assigned IP 
20 address for the MAC of the packet 

5 . The Registration Driver, not able to find an entry ft r that MAC assigns a new 
IP address fiom the pool of available IP addresses. 

6. The Packet Driver performs NAT on the ARP packet (as necessary). 

7. The Packet is passed on to the ARP handler. 

25 8. The ARP Handler sees that the Source IP address is Equal to the Destination 
IP address and drops the ARP request 
9 . Eventually the client times out and as sumes that it is the soiji owner of that IP 
address on its network. 

30 DHCP 

Scenario: Client is configured for DHCP. 
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1. Client computer makes a DHCP DISCOVER request 

2. ThJs request is intercepted by the packet driver who aaks the registration driver 
for the assigned IP address for this MAC 

3. The registration driver will attempt to lookup the assigned! IP address for the 
5 MAC and if it not found create a new assignment based cm its pool office 

addresses, 

4. The packet driver will NATthe request as wqmr^ and fbrv^hto the DHCP 
server. 

5. The DHCP server will lookup the as signed IP address for th^ MAC address and 
10 return a DHCP OFFBR response for that address, I 

6. The ASP handler looks up the MAC address for the destination address from 
the Registration Driver and inserts that MAC address into the packet 

7. The packet driver will intercept the response and perform ijjAT if required. 

8. The user's DHCP client will respond with a DHCP REQUEST forthe assigned 
IS IP address. 

9. . The packet driver will intercept the request, perform NAfT if required and 

forward the request to the DHCP server. 

10. The DHCP server will lookup the assigned IP address for thelMAC address and 
return a DHCP ACK response for that address. 

20 11. Hie ARP handler looks up the MAC address for the destination address from 
the Registration Driver and inserts that MAC address into the packet 

12. The packet driver will intercept the response and perform NAT if required. 

13. The client obtains the IF address. 

25 BROWSER STARTUP 

i 

Scenario: Client starts their WEB browser, and attempts to load a WEB page. 

1. Client starts WEB browser. 

2. Browser needs to look up the IP address of the WEB server so it generates a 
DNS request, 

30 3. SolutionIP server picks up the DNS request and passes it to the Packet Driver. 
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4, The Packet Driver asks the Registration Driver to look ujp the Assigned IP 
address for the MAC of the packet. 

5, The Registration Driver returns die ATP to the Packet DriVer. 

6, The Packet Driver performs NAT, if necessary. 

5 7. The packet is passed on to the Packet Filter that redirect^ the request to the 
SolutionIP DNS server. 

i 

8. The DNS server looks vp the HTTP server and creates a response for the client 

9. The response packet goes to the ARP handler that asks the Registration Driver 
to look up the MAC address for the client and then the AR^ handler adds it to 

10 the outgoing packet 

10. The packet is then passed to the Packet Driver that looks bp the Original IP 
address for the Assigned IP address and performs NAT if nlsoessary. 

U. The response Is sent back to the client 

12. The client will generate an ARP request for their gateway server (assuming that 
15 the IP address returned for the HTTP server was not local, ijrit is local then the 

client win be requesting the MAC of the HTTP server instead). 

13. The SohrtionDP server will pick up the ARP request and pjtss it to the Packet 
Driver. 

i 

14. TTie Packet Driver will ask the Registration Driver to look vp the Assigned IP 
20 address for the MAC of the packet 

15. Hie Registration Driver will return the AIP to the Packet Driver. 

16. The Packet Driver will perform NAT as necessary. 

17. The ARP request is passed on to the ARP handler 

13. The ARP handler generates arc spouse saying that the SolutionlP server's MAC 
25 is the MAC for the requested IP address. 

19. Ike ARP response is passed back to the Packet Driver. 

20. The Packet driver looks up die OIP of the packet destination using the AIP and 
performs NAT if necessary. 

21. The ARP response is sent back to the client 

30 22. The Client then sends a HTTP request to the IP addiesB returned by fte DNS 
to the MAC address returned by Hie ARP response. 
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23, Tho HTTP request arrives at the SoluttanlP server and is passed to tha Packet 
Driver, 

24, Tlie Packet Driver gete the Regi^^ 
and performs NAT if necessary. 

i 

5 25, The Packet is Passed to the Packet Filter which detonines that the client is 
unregistered 

26. The Packet is redirected to the Redirection Web Server (solhttpd), 

27. The Packet is redirected to the Registration Web Server. 

28. The Registration Web Server generates the response to thejHTTP request 
10 29. The Packet is passed back to the ARP Handler that lojoks op the MAC 

associated with die ATP of the client and updates the packet 
30. The Packet is passed back to the Packet Driver that looks up qieOIP associated 

with the AIP and performs NAT if necessary. 
31- The response is passed back to the client 
15 j: 

The conversation will continue from here but the form will be similar to the above. 

CLIENT REGISTRATION 
Scenario: havhig been redirected 
20 for the service. 

PORT BASED 

Scenario: the client is plugged into a switch port on which port-based authentication 
has been configured. 

25 1. The client accesses the registration web page that triggers the execution of a 
CGI script 

2. The CGI checks the database and determines that port-based authentication has 
been configured. 

3. The CGI requests the MAC address and physical port information for the 
30 assigned IP address from Soln Daemon. 
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4. Soln Daemon asks the registration driver for the MAC address associated with 
the assigned IP addreSB given. 

5. . The registration driver returns the MAC address associated with the assigned 

IP address. j 
5 6. Soln Daemon asks Salsnmpd for the physical port number associated with the 
given MAC address. 

i . 

7. Solsnmpd returns the physical port information after resolving the port based 
upon the given MAC address. 

8. * Soln Daemon returns the MAC address and physical port nfonnation based 
10 upon the assigned IF address given. 

9. The CGI requests room number and fee Information from tli£ database for the 
physical port number. 

10. The databaso returns the room number and fee information f<# the physical port 
given. j 

15 11. The CGI dynamically generates HTML for the client that reacts the room and 
fee information returned from the database. 

1 2. The client chooses to accept the foes and oontimie with registration. 

13. The CQI requests registration for the assigned IP address from the Soln 
Daemon. 

20 14, The Soln Daemon asks the driver to register the entry with ihe given assigned 
IP address* 

IS. The CGI inserts the client's information into the database anid forces the portal 
page to tho client 

25 ACCESS CODE 

Scenario: the client is plugged into a switch port on which part baied authentication 
has not been configured and access codes are enabled on this installation. 
1. The client accesses the registration web page that triggers the execution of a 
CGI script 

30 2. The CGI checks the database and determines that port based authentication has 
not been configured and access codes are enabled. 
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i 

3. The CGI dynamically generates HTML for Hie client that rejflecte need for them 
to enter access code Information. 

4. The client enters access code information into the form. ! 

j 

5 . Toe C GI reque sta the room number and fee inform action fr&mtho detabas e far 
5 the given access code. 

6. The database returns the room number and ^infonnationfbr the given access 
code. 

7. The CGI dynamically generates HTML for the client that reflects the room and 
fee information returned ftom the database. 

10 8. The client chooses to accept the fees and continue with reipstretion. 

9. The CGI requests registration for the assigned IP addrsss fiom the Sola 
Daemon. 

10. The Sola Daemon asks the driver to register the entry with <he given assigned 
IP address. 

IS 11. The CGI inserts the client's information into the database ajiid forces the portal 
page to tiie client 

AUTOMATIC 

Scenario: the server has been configured to automatically register new clients. The 

20 

main effect here is that clients ere always directed to the portal page the first tfano fluey 
access the WED. 

1. The client is redirected to the registration web page that triggers the execution 
of a CGI script. 

2. The CGI requests registration for the assigned IP address from the Soln 
25 Daemon. 

3. Hie Soln Daemon asks the driver to register the entry with the given assigned 
IP address, 

4. The CGI forces the portal page to the cHent 
30 CLIENT E-MAIL 
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REGISTERED . j 
SENDING 

Scenario: A registered client is attempting to send an e-mail using their e-mail client 
5 software (Netscape, Outlook, Pegasus, etc.) 

1 . The client sends the e-mail using their preferred client software and configured 
outgoing SMTP mail server. 

2. Moil client looks up SMTP server's IP address using DNSJ : 

3. Mail client looks up the MAC address of either the SMTP server or their 
10 gateway using ARP, j 

4* The Packet Filter transparently redirects all SMTP traffic fin Registered clients 
to the local SMTP server. 
• 5. The SMTP server acts as a proxy and sends the e-mail on tosjialf of the client 

i 

: 

IS UNREGISTERED 
POPPING 

Scenario: An unregistered client is attempting to pop their e-mail; from their home 
system using their e-mail client software (Netscape, Outlook, Pegajius, etc.) 
20 1. Client looks up POP server's IP address using DNS, 

2. Mail client looks vp the MAC address of either the POP server or the gateway 
using ARP. 

3. The Packet Filter transparently redirects all POP3 traffic for unregistered 
clients to the local POP3 server. 

25 4. The POPS server accepts any username and password combination and delivers 
a single new e-mail message to the client 
5. This e-mail typically informs the client that they have not registered for the 
service and instructs them how to do so* 

30 CLIENT TRAFFIC (GENERAL) 
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DHCP 

Scenario: A DHCP configured client sends and receives packets through the SolutionlP 
server* 
SENDING 

5 1. Client generates a packet for a remote host touted through the Solution!? 
Server. 

2. SolutionlP Server receives die packet and posses it to the pa cke t driver, 

3. The packet driver examines the packet and looks up the AIP in the Registration 
Driver using the MAC address. 

10 4. The packet driver determines that the ATP and the original Source address are 
equal and that NAT is not necessary. 
5. The packet Is passed to the packet filters see the Registered and Unregistered 
sections below. 

IS RECEIVING 

: 

1> Packet is passed from the packet filters to the ARP handled. 

i 

2. The ARP handler will look up the MAC address of the destination boat of this 
packet. 

3. The paoket will then be passed on to the packet difver that will look up the 
20 entry for the Assigned IP address and determine that do NAT is necessary. 

4. The Packet will then be transmitted to the client. 

NAT 

Scenario: A Fixed IP configured client sends and received packets through die 
25 SolutionlP server. 

SENDING 

1. Client generates a packet for a remote host routed through their gateway 
(however the SolutionlP server will claim to be that gateway when the client 

30 makes their ARP request) 

2. The SolutionlP Server receives the picket and passes it to the packet driver 
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3. The packet driver examines the packet and looks up the AIP in the Registration 
Driver using the MAC address. 

4. The packet driver determines that the AIP and the original Source address are 
not equal and that NAT is necessary. 



5. The packet la NATed and passed on to the packet filters see 
Unregistered sections below. 



the Registered and 



RECEIVING 

1. Packet is passed from the packet filters to the ARP handled 
10 2. The ARP handler will look up the MAC address of the destination host of this 
packet 

3 . The packet will then be passed on to the packet driver thai will look up the 
entry for the Assigned IP address and determine that NAT is necessary, 

4. The packet driver will perform NAT on the packet and transmit the packet to 
IS the client. 

REGISTERED 

ROUT ABLE 

20 Scenario : Traffic ftom and to a registered client with a mutable assigned IP address is 
received and scut by the SolutinnTP server. 



SENDING 

I. Packet is received by the packet filters. 
25 2. It is detemined that the packet can be forwarded. 

3. Packet is forwarded out the appropriate external Interface, through Hie 
appropriate router. (Usually there is only one external intofece and one router) 

RECEIVING 

30 1. Packet is received by the external interface. 
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% Packet ifi passed to the packet filters and it is determined that it may be 
forwarded* 

i • 

3. Packet is passed on to die ARP handler to have the appropriate MAC added. 
(See the appropriate NAT or DHCP Readying section above.) 

5 

UNROUTABLE (Masqueraded) i 
Scenario: Traffic ftcm and to a registered client with a unroutable aligned IP address 
is received and sent by Hie SolutionIP server which configured tj> masquerade the 
unrentable addresses. 

10 

SENDING j 

1. Packet is received by the packet filters, 

2. It is determined that the packet is to be mas queraded. p 

3. The packet Alters assign a port on the Solution!? server for the source port of 
15 this client 

4. The packet is transmitted NAPTed so it looks like it came frW the SolutionIP 
server on the assigned port. 

RECEIVING 

20 1. Packet is received by the mrternai interface 

2. Packet is passed to the packet filters and it is determined ihat this port is a 
masqueraded port and the packet must be reverse NAPTed so it has the 
appropriate destination port and IP address. 

3. The packet filters determine that the packet may be forwarded 

25 4. The packet is passed on to the ARP handler to have the appropriate MAC 
added. (See the appropriate NAT or DHCP Receiving section above.) 

UNREGISTERED 

Unregistered client traffic in general is blocked by the SolutionIP server packet filter 
30 rules. 
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CLIENT EXPIRY 



10 



15 



20 



2. 



3. 



UNREGISTER 

Scenario: A registered client has reached thdr lustration expiry time. 
1. The client is using various Internet services. 

The Registration Device Driver (Sain Device) executes its purge function 
(NOTE: this happens on a configurable periodic schedule)] 
The purge function determines that the client's registration expiry time is less 
than the current time. 

The purge Amotion sets the cntiy to unregistered and calculai os the entry expiry 
time (NOTE: the actual behavior depends on the expiry m< ido). 
The Packet Filters allow any established connections to xm aain open. 
The next htlp request initiated from the client as handled as previously 
described (see Browser Startup). 



5. 
6. 



PURGE 

i 

Scenario: An unregistered client has reached their entry expiry time, and they are 
inactive. 

1. The client has disconnected from the network or otherwise become idle. 

2. The Registration Device Driver executes its purge tuncuon, 

3. The purge function determines that the client's entry expiry time (calculated as 
* the last used time phis the inactivity grace period) is less than the current time, 

4. The entry is deleted from the Registration Driver. 

5. Any future traffic from the client will be handled as previously described (see 
25 Client Startup). 



VLAN SERVICES BY THE SolntionIP SERVER 

Fig. 15 shows an example of the VBN server according to the first embodiment. 
Raftering to Fig. 15, the TON Server 1000 comprises Packet 1^ 
30 Device Driver 1004, Registration WEB Server 1014 and Solsnmpd 1018. 
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Tbe Packet Driver 1003 includes Ito fractions of the Packet Driverk 303 and 903 . The 
Registration Device Driver 1004 includes the functions of the Registration Dovioe 
Drivers 304 and 904. The Registration WEB Server 1014 includes tjie functions of the 
the Registration WEB Servers 314 and 914. The SoUnmpd jdlg includes the 
S Amotions of the Solsnmpd of the SolutionIP Server 202 and the Stilsnmpd 90S. 

i 

i 

Interior interface 1002, IPFW Input Rules 1005, IPWF Foraardingj Rules 1006, ARP 
1007, Exterior Interfiice 1008,TCP/IP SockBt Interface 1011, DNS jl012,POP3 1013, 
Sola Daemon 1015, DHCP 1016 and Command Line Interface 1017 are similar to 
10 Ihteriorinfea^e302,IPFWfapWBi^ 

Extaior Ioterikce308, TCP/IP Sock^ 313,SolnDemon 
315, DHCP 316 and Command Line Interface 317 respectively. Client(Hotel guest) 
301 is connected to the Interior interface 1 002 via the coze-leaf switches. 

i 

i 

j . 

IS According to the aforementioned invention, useMo-setver securitjj is automatically 
provided using VLANs whose management is automated by the server. The server 
fa cili tat es user initiated group collaboration by placing users requesting the service in 
the same VLAN, Additionally, the limit on the number of VLANS can be extended 
through creative use of the filtering policies on the switching inirastmcture. Further, 

20 user-to-server security is provided by piecing each individual user into separate 
VLANs, The server's automation and Hifmaganflnt of VLAN creation/deletion 
facilitate this process, winch allows user to control groupings of users into common 
VLANs (Le. group collaboration). Further, the filtering policies implemented on the 
switches allow users to utilize a broad range of VLANs. 

25 

Second Embodiment 

An on-demand Rentable IP address service according to a second embodiment will 
be described in detail with reference to die drawings. The reassignment of addresses 
is handled using a customized DHCP and minimal user intervention. 

30 

The main features of the on-demand mutable IP address service comprise: 
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• control of IP assignment by the VBN Server or the iSolutionIP Server 
described above such that it can dynamically reassign XP addresses on demand. 

ReaUP 

5 A preferred embodiment of the second aspect of the invention will! be referred herein 
as ReaUP. 

ReaUP is an Internet Protoco](IP) address allocation technology that enables a 
Dynamic Host Configuration (DHCP) Server to allocate both ljoutable and non- 
10 mutable IP addresses, initiated by Che end-user. 



IP addresses are utilized by devices communicating with the TCP/IP protocol(the 
communication protocol of the Internet) to determine the routing o4 network traffic to 
and from clients. Typically , network clients are configured either with a static IP 
address car to request the allocation of an IP address from a DHCP ^orver. 



15 



When a client configured for DHCP is initially connected to a TCP/IP network, it 
issues a broadcast message requesting an IP address. Typically, the DHCP server will 
respond with an IP address allocated form a pool of addresses that it maintains. The 
20 DHCP server can maintain pools of both rentable and non-routablc addresses. 



Routable and non-routable addresses differ fundamentally in that devices with non- 
routablc addresses must initiate any communication. Devices with routable addresses 
may be contacted by other devioes without 
25 difference is of interest in the user of Visitor Based Notwcoriks (VBNs). A VBN is one 
in which clients connect for temporary access to network for Internet services. 

A common implementation of a VBN is a hotel service in which guests may connect 
to a hotel gateway server for Internet access. Since the number of available routable 
30 IP addresses in this situation is typically smaller that the number of connections 
available to guests, a pool of non-routable IP addresses is generally utilized by the 
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VBN DHCP server. However 9 this practice limits the capabilities that a guest has 
available from such a VBN connection. For example, a camnjtfm use of digital 
communications is NetMeetmg(trado-mark), in which a number qf participants may 
interact electronically through a NetMeeting server hosted by one of the participants. 
S Without a routable IP address, the hotel guest is unable to host 4iich a meeting for 
others who are participating via the Internet 

OVERVIEW 

' i 

The ReaUP system of the second embodiment allows a network clicjrit to request either 
10 a routable or non-routable IP address dep ending on the client need, the ReaUP service 
executes on a variety of operating systems. The preferred embodiment is based on a 
Linux operating system. 

j 

The ReaUP system according to Hie second embodiment comprises; 
15 1. Common gateway Interface (CGI) component accessed via Hypertext Markup 
Languagc(HTML) pages; 

2. Registration Driver inc or p ora t e d into the VBN kernel; and 

3. Custom built DHCP server. 

20 The following paragraphs describe in more detail the technology encapsulated by 
ReaUP. 

COMPONENTS AND INTERACTIONS 

Fig. 1 6 shows the breakdown of the core components end their interactions of the VBN 
25 Server (ReaUP) 1100 according to the second embodiment The VBN Server i 100 
comprises Registration Device Driver 1102, Registration WEB Server 1104 and 
DHCP Server 1106. 

REGISTRATION DEVICE DRrVER(sometimes referred to as Soln Device) 
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Tha Registration Device Driver 1102 is incorporated into the VBNj Operating System 
(OS) Kernel. Hie Registration Device Driver 11 02 is a pseudo driver in that it is not 
actually associated with any physical device. , 

5 The Registration Device Driver 1 1 02 maintains the pool of IP addresses rather than the 
DHCP Server and maintains a mapping of registered clients and assigned addresses. 
In this manner, the Registration Device Driver 1 102 maintains both a pool of routablc 
addresses 1 108 and a pool of non-rouiable addresses 1110. 

10 The Registration Device Driver 1102 also maintains the driver state information 
including a range type that is used to indicate what ranges are rentable and nan- 
routable(Premium/RflalIP or Standard) 



According to the functionality of the Registration Device Ipriver 1102, the 
15 reassignment of user IP addresses from rentable to non-routable! and visa-versa is 
properly handled. 

REGISTRATION WEB SERVER 

The Registration WEB Server 1 104 is a WEB Server that serves local content for the 
20 VBN Server 1100, This includes the Registration WEB pages, fhoadm 
pages and Configuration WEB pages. 



The Registration WEB pages serves as a client' s gateway to the services provided by 
the VBN Server 1100. The registration pages offers the clients the opportunity to 
25 access RcallP. 



DHCP SERVER 

The DHCP Server 1 106 issues the request command to flic Registration Device Driver 
1 1 02 according to the user's request The Registration Device Mver 1102 wiU assign 
30 the address based on the request command. 
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THE FUNCTION OF THE ReaHP 

When the DHCP server 1106 is contacted upon cUemcomiectiOT(stos61), the DHCP 
server 1 1 06 requests a non-rouiablo EP address to the Registration Device Driver 1 102 
(step s62).By receiving the request for a non-rentable IP address, the Registration 
5 Device Driver 1 102 assigns a non-routable IP address from the pool of non-routable 
addresses 1110 (step s63). The DHCP server 1106 receives the ntm-toutable IP address 
from the Registration Device Driver 1102. Therefore, the non-routable address is 
assigned to the client 

i 

10 The client may interactively request the use of a routable IP address through HTML 
pages (Registration page U 12) whichresideon the VHN server 110^(step s64). When 
the CGI components 1 1 14 that underlie the functionality of the KT^iL pages accepts 
the request for a routable IP address(step s65) , the COI cjdmponents 1114 
communicate the request to the Registration Device Driver 1102.! The Registration 

15 Device Driver 1102 records reglstrauon(step 866), 

The Registration Device Driver 1 102 responds with an address allocated from the pool 
of routable addresses 1 108 (step »69), and releases the temporary non-routable IP 
address previously assigned. The DHCP server 1 1 06 receives the routable IP address 
20 from the Registration Device Driver 1 102 .The routable address is assigned to the 
client. 

Since the Registration Device Driver 1102 xnaintains the mapping of clients to 
allocated IP addresses, both routable and nra-roirtable addresses may be assigned on 
25 request! 

REGISTRATION PROCESS-ROUTABLE IP SERVICE 

Fig.17 shows a process for registration for routable IP service according to the second 
embodiment Registration Device Driver 1202 and VBN Web Server 1204 in Fig. 17 
30 correspond to the Registration Device Driver 1 102 and the Registration WEB Server 
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11 04 in Fig. 16 respectively. Switch Commander 1206 corresponds to the Switch 
Commander 917 inFig.3. 

Step s71: The Client/Browser 915 sends data including room number, 
registration type(Routable IP Service) to the VBN Web Server 1204, 
If subscribing to ReallP service, the lease period will also be sent 
Step s72: The VBN Web Server 1204 passes data to the Registration Device 
Driver 1202. 

Step a73; The Registration Device Driver 1202 will send two fcbmmand requests 
to the Switch Commander 1206* The first oomn^nd will create a 
unique Routable-IP VLAN. The second will add th^ user's port to the 
Routable-IP VLAN, 

Stop s74: For each command completion, the Switch Combandar 1206 will 
report command status to the Registration Device I>river 1202. 
IS Step 875: If the commands are successful, the Registration Device Driver 1202 

i 

will register the user by aligning axoutablc IP address and sending the 
port, IP address and registration type to the IP Billing database 1208. 
Step s76: Registration status is returned to the VBN Web Server 1 204. 

20 It will be understood by those skilled in the art that ReallP may also execute on UNIX 
type operation systems. 

It Is noted Oat the ReallP 1 100 can allow usera to change their IP addresses from 
rentable to non-mutable. 

25 

ReallP SERVER 

ReallP Server according to the second embodiment will be described. As mentioned 
above, fee ReallP is the capability of allowing users to change their IP addresses from 
one pool of addresses to a different pool of addresses, specifically from non- 
30 routable(Standacd Internet) to routable (P remium Internet) and visa^-versa. 
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The Real IP Server further extends the ReallP concept to allow! pools of rentable 
addresses to be maintained on one or more remote servers which may or may not males 
those same pools available to other VBN Servers (or the Solution!! 5 Servers), 



IS 



20 



25 



1 tunnel 

involves the VBN Server connecting to the ReallP Server. 
^acUertregiste*^ 

the VBN Server requests a. ReallP from tlie ReallP Server. The VBN Server aaka for 
10 an IP address which it then offers to its client as If the address were available locally. 

i 

Traffic from the client will be routed through the tunnel to the ReallP Server that 
supplied the address. The Traffic to the client wfll be routed the ReallP Server, and 
thence through the IP tunnel to the VBN Server and on to the clierk. 



Fig. 18 shows en example of a combination with ReallP Serve* and VBN Server 
according to die second embodiment Referring to Fig. 18, clients CI and C4 are 
normal clients. The Clients CI and C4 connect through their VBN Server to the 
Internet 1302. 

THE BASIC SCENARIO 

The client C4 wants a routablc IP address. VBN Server 1 304A does not have arouiable 
address pool or it has run out of rentable addresses. ReallP Server 1300 has an 
address available. 



1. The VBN Server I304A connects to the ReallP Server 1300 via the Internet 
1302 and requests a address. 

2. The ReallP Server 1300 returns a routahle address to the VBN Server 1304A 
baaed on the request from the VBN Server 1304 A. 

30 3. The VBN Server 1304A then provides the routable IP address tome client C4. 
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As far as the client is concerned, the Mutable IP address is locally provided. At this 
point, traffic from the client can be sent directly to the Internet 1302 and traffic to the 
client will go to the ReallP Server 1300 through the tunnel to the VBN Server 13 04 A 
and then to the client C4. 

5 

The other scenarios are all variations to the basic scenario described above. 
ANOTHER SCENARIO 

The following scenario involves VBN Server 1304B and the client CI connected to 
10 the VBN Server 1304B. The VBN Server 1304B accesses the 'internet 1302 via 
Internet Service Provider(ISP) 1306. In the ISP 1306, client's network address is 
processed by the Network Address T^anslation(NAT).Thei^orei itfae VBN Server 
1304B could not normally supply mutable IP addresses to it's clients. 

15 However, with the ReallP Server 1 300, and by routing outgoing client traffic through 
the tunnel rather than directly to the Internet 1302, the VBN Server I304B can provide 
routable IP addresses to it's clients. 

Numerous modifications, variations and adaptations may be made. In Pig. 1 8, client 
20 C2 accesses the Internet 1302 via ISP 1306 and client C3 accesses the Internet 1302 
directly. A farther extension to lids invention is to provide software to the clients C2 
and C3 that will allow them communicate directly with the ReallP Server 1300 and 
make use of ReallPs supplied by the ReallP Server 1300 directly. In this case, me 
client would always route outgoing traffic through the tunnel, as it could not be sure 
25 that the olient is not behind NAT process of ISP 1306 . 

Third Embodiment 

A system according to a third embodim^ is described with reference to Figs. 19-23. 
In Figs 19-23, "Q°,"U",and " VLID" designate 802.1Q tagged, untagged and VLAN 
30 ID, respectively. The system of me third embodiment encompasses both ReallP and 
rVLAN. 
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Fig. 19 shows the core components of the system according to thejthfad embodiment 
Referring to Fig. 19, the con switch SO oonnects to the VBN Server 930 via internal 
port 933 and leaf switches S1-S4. The leaf switches connect the room ports to the 
core switch SO. The VBN Server 930 connects to the Router 934 via external port 93 5. 

The VBN Server 930 comprises ; 

1. Registration Driver which tracks client registration and VL ANs defined on the 
switches; 

2. Packet Driver which processes packets leaving the client LAN by removing 
VLAN tag ( convert 802.1 Q to standard format ) and fctaooesses packets 
entering the VLAN by tagging packets ( convert standard format to 802.1 Q); 

3. . DHCP Server which is customized to return IP addresses jfrom routable and 

non-mutable pools assigned by the Registration Device Driver, 

4. IPWF which redirects non-registered clients to Registration Server 931 and 
15 provides IP masquerading for Standard Internet Service clients; 

5. ARP Server which is customized for clients with static IP configuration. Hie 
server returns the -hardware address of it's internal port tegaxdiess of the 
gateway IP specified by the client 

6. Solsnmpd which issues SNMP commands to the switches to return the status 
20 and configure VLANs. 

The Registration Server 93 1 comprises; 

1. Registration component which provides a HTML pages to regbtsr/unrogister 
for Standard Internet and Premium Internet as well as provide Group Access 

25 services ;and 

2. Virtual Concierge component which provides infbrmation relevant to the hotel 
and local community (e.g. hotel services, restaurants, museums, theaters, etc.) . 

IP Billing databaso 932 records services registrations and provides/contains the 
30 applicable usages fees from the Billing Software, 
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The core switch SO forwards or filters traffic based an the VLID specified in the Q-Tag 
inserted in the Ethernet frame. 



Standard Internet Service is provided when clients have non-iouteble IP addresses. 
5 Premium Internet Service is provided when clients have routablc IP addresses. ReallP 
enables users to switch their addresses between non-routable and routable. IVLAN 
enhances ReallP, by putting clients registered for Internet access into private VLANs 
l whether their addresses are routable or non-routable so their traffic to the server is 
protected from other client's traffic. Hie core switch SO with the filtering capabilities 
10 enables their traffic to be protected 

Figs. 20-23 show various user scenarios possible using the architecture shown in 
Fig.19. The scenarios are illustrated using a client with a! dynamic TQP/IP 
configuration ( that is , it uses DHCP) , The Standard Internet Service and the various 
IS Group scenarios can also be used by astatic client The only difference mtheacfcnario 
^ steps for DHCP and fixed clients are the following 3 steps* 
For the static client these steps would be as follows; 

1. The client plugs in, The client broadcasts an ARP request to discover the 
hardware(Le. MAC) address of it's configured defiuilt gateway. 
20 2. The VBN Server 930 detects the client traffics and assigns an IP address from 
a pool of standard non-routable IP address. This assignment is recorded in an 
operating system kernel registration structure that also tracks such information 
as the client's MAC, room number and original IP address. 
3. In response to the ARP request, the server responds with it's internal port 
25 hardware address regardless of die IP specified. 

STANDARD INTERNET SERVICE REGISTRATION 

Standard Internet Service is a basic form of Internet access which will be provided to 
users for basic web surfing and the collection of remote e-maiL Fig.20 depicts a 
30 scenario where the usee connected to switch Sl^Port 2, registers for Standard Internet 
, Service. 
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Scenario; 

1. The client plugs In to leaf switch 81 .port 2, The client software sends a DHCP 
request to the VBN Server 930. 
5 2. The VBN Server 930 detects the oliant traffic and assigns an IP address from 
a pool of non-routable IP addresses. This assignment is recorded in an 
operating system kernel registration structure that also tracks the client's MAC, 
room number and original IP address. 

3. The DHCP Server of the VBN Server 930 returns the assigned IP address to 
10 the client 

4. The client opens a Web browser and is redirected to the Registration page by 
a firewall role installed on the VBN Server 930. The user! selects "Standard 

« 

Internet Service". 

5. Registration for Standard Internet Service results In the following: 

15 • For billing purpose, the service registration is recorded in the IP Billing 
database 932. 

• The Registration Driver of the VBN Server 930 assigns the client to the next 
available Internet service VLAN ID. For this scenario, the client is assigned to 
"VLAN 3" withVLID3. 

20 • The registration process creates "VLAN3 " on S 1 and adds the user 1 b port(2) to 
the definition as untagged. To communicate with the core switch SO, downlink 
port (26) of the leaf switch SI is added to the VLAN as 802. 1Q tagged. 
To oommimionte with the VBN Server 930, " VLAN3 » is created on the core 
switch SO. " VLAN3" member ports include 3 (uplink to die leaf switch) and 

25 2(downlinkto the VBN Server 930). Bom ports are specified as 802.1Q tagged; 

• The Registration Driver of the VBN Server 930 records the necessary VLAN 
information. 

6. When registration is complete, the user can access the Internet 936. 



30 



Standard Internet users will always have their IP address masqueraded to the IP 
address of the SolutionlP Server's gateway( XXXX). If mere is another client in 
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a VLAN with VTJD 3 defined on switch S4, the cHents( SI and 84) are mutually 
exclusive by forwarding roles specified in a packet filter installed on the core switch. 
This prevents their clients from seeing each other's network traffic, and is the 
m echan i sm used to overcome the VLAN limitations of the switches. 

5 

Whan a Standard Internet Access Service usage period expires, the software sha ll: 

a) remove the user port from the Internet VLAN; 

b) add the user port back to the Open VLAN(VLAN 10=2); 

c) remove the downlink port on the user leaf switoluajidthea^wnlinkportojiatiy 
10 cascaded switches between the user leaf switch and the c^to switch, fium the 

Internet VLAN; 

d) remove the VLAN definition from the user leaf switch; 

e) remove the uplink port on the core switch S0( to the user leaf switch) form the 
Internet VLAN; 

IS f) remove the downlinkport on the c«reswitimCtothev^NSe^930) from the 
Internet VLAN, if no other leaf switch contains the VLAN definition; 

g) remove the VLAN definition from the core switch, if no other leaf switches 
contain the definition; and 

h) return the Internet VLAN ID back to the pool of Standard Internet Service 
20 VLAN IDs. 

It is noted that "an Internet VLAN" is a VLAN group with only one member for the 
purposes of providing client security. Far convenience a range of VLAN IDs are 
selected for use exclusively for Internet VLANs. This range is used in configuring the 
25 core switch so Internet VLAN IDs can be re-used on multiple leaf switches without 
allowing clients in the same VLAN to cominunicate. 

PREMIUM INTERNET SERVICE REGISTRATION 

Premium Internet service will be offered for those VBN users who require the use of 
30 anwtable IP address fbrtheuseofVPNsofi^ 

of files( e.g. a web server) for external access outside the VBN network. 
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Fig.2 1 shows a scenario where the user connected to switch S4JPort 1, registers for 
Premium Internet Service. 

Scenario; 

5 1. A ujot is currently registered on^ 

Service. This client has been assigned VLAN ID3(VLIEH3). 

2. A user is currently registered on the leaf switoh S4 jwrt 9 ffor Standard Internet 
Service. This client has been assigned VLAN DD3(VLn>±3) f 

3. A new client plugs in to the leaf switch S4 , port L The client software send 
10 a DHCP request to the VBN Server 930. 

4. The VBN Server 930 detects the client traffic and assigns an IP address from 
a pool of non-routable IP addresses. This assignment is recorded in an 
operating system kernel registration structure that also tracks the clients MAC, 
room number and original IP address. 

IS 5. The DHCP Server of the VBN Server 930 returns the assigned IP address to 
the client* 
6. The client opens a Web browse 

a firewall rale installed on the VBN Server 930. The user selects ■ 'Premium 
Internet Service 11 . 

20 7. Registration for Premium Internet Service results in die fbllcwmg: 

• The client is assigned aroutable IP address. 

• The client's registration record is modified by replacing the ennenfly assigned 
IP with the routahle IP address. 

• For billing purpose, the service registration is recorded in the IP Billing 
25 database 932. 

• The Registration Driver of die VBN Server 93 0 assigns the client to the next 
available Internet service VLAN ID. For this scenario, the client is assigned to 
"VLAN 4" with VLID4. 

• Hie registration process creates fT VLAN4 w on the leaf switoh S4 and adds the 
30 user's port(l) to the definition as untagged. To communicate with the core 
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switch SO, downlink port (26) of the leaf switch S4 is added to the VLANaa 
802.1 Q tagged. 

To communicate with the VBN Server 930, " VLAN4" is created on the core 

switch SO. " VLAN4" member ports include 8(uplink to the leaf switoh) and 
5 2(downlkiktothe VBN Server 930). Both porta eie specified as 802.^ 

• The Registration Driver of the VBN Server 930 records the necessary VLAN 

information including the configuration of the switches. 
8. When registration is complete, the user can access the Internet 93 6 and externa] 

users can route directly to the olient PC. 



10 



IS 



TwoeUentsareregiirtsredwifo 

switch S4. The traffic for these 2 clients , SI and S4, maintains mutual exclusivity by 
forwarding rules specified in a packet filter installed an the core switch SO. This 
prevents these clients from seeing each other's network traffic. 



When a Premium Internet Access Service usage period expires, the software shall : 

a) remove the user port from the Internet VLAN; 

b) add die user port back to the Open VLAN (VLAN Il>=2); 

c) remove the dovmlinkport on the user leaf switch, and the downlink port on any 
20 cascaded switches between the user leaf switch and the care switch, from foe 

Internet VLAN; 

d) remove foe VLAN definition from the user leaf switch; 

e) remove the uplink port on foe core switch S0(tofoe user leaf switch) form foe 
Internet VLAN; 

25 f) remove foe downlink port on the core switoh( to foe SohitimuT server 930) 
from the fotemetVI^.tfra 

g) remove the VLAN definition from the core switch, If no other leaf switches 
contain (he definition; and 

h) return foe Internet VLAN ID back to the pool of Premium Internet Service 
30 VLAN IDs. 
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